FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

tools: update gyp-next to 0.18.1 · nodejs/node@6409b1f · GitHub

/ node Public

Commit 6409b1f

Browse files
nodejs-github-bot
authored and
RafaelGSS
committed
tools: update gyp-next to 0.18.1
PR-URL: #53251 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
1 parent 718a3ab commit 6409b1f

11 files changed

Lines changed: 3133 additions & 3 deletions

‎tools/gyp/CHANGELOG.md‎

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,17 @@
11
# Changelog
22

3+
## [0.18.1](https://github.com/nodejs/gyp-next/compare/v0.18.0...v0.18.1) (2024-05-26)
4+
5+
6+
### Bug Fixes
7+
8+
* **ci:** add Python 3.13 pre-release to test matrix ([#257](https://github.com/nodejs/gyp-next/issues/257)) ([8597203](https://github.com/nodejs/gyp-next/commit/8597203b687325c7516367135e026586279d0583))
9+
10+
11+
### Documentation
12+
13+
* vendor docs from gyp.gsrc.io ([#254](https://github.com/nodejs/gyp-next/issues/254)) ([8d7ba6e](https://github.com/nodejs/gyp-next/commit/8d7ba6e784dedf1122a0456150c739d2a09ecf57))
14+
315
## [0.18.0](https://github.com/nodejs/gyp-next/compare/v0.17.0...v0.18.0) (2024-05-08)
416

517

‎tools/gyp/CONTRIBUTING.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,9 @@
11
# Contributing to gyp-next
22

3+
## Start contributing
4+
5+
Read the docs at [`./docs/Hacking.md`](./docs/Hacking.md) to get started.
6+
37
## Code of Conduct
48

59
This project is bound to the [Node.js Code of Conduct](https://github.com/nodejs/admin/blob/HEAD/CODE_OF_CONDUCT.md).

‎tools/gyp/README.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
GYP can Generate Your Projects.
22
===================================
33

4-
Documents are available at [gyp.gsrc.io](https://gyp.gsrc.io), or you can check out ```md-pages``` branch to read those documents offline.
4+
Documents are available at [`./docs`](./docs).
55

66
__gyp-next__ is [released](https://github.com/nodejs/gyp-next/releases) to the [__Python Packaging Index__](https://pypi.org/project/gyp-next) (PyPI) and can be installed with the command:
77
* `python3 -m pip install gyp-next`

‎tools/gyp/docs/GypVsCMake.md‎

Lines changed: 116 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
1+
# vs. CMake
2+
3+
GYP was originally created to generate native IDE project files (Visual Studio, Xcode) for building [Chromium](http://www.chromim.org).
4+
5+
The functionality of GYP is very similar to the [CMake](http://www.cmake.org)
6+
build tool. Bradley Nelson wrote up the following description of why the team
7+
created GYP instead of using CMake. The text below is copied from
8+
http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg11029.html
9+
10+
```
11+
12+
Re: [webkit-dev] CMake as a build system?
13+
Bradley Nelson
14+
Mon, 19 Apr 2010 22:38:30 -0700
15+
16+
Here's the innards of an email with a laundry list of stuff I came up with a
17+
while back on the gyp-developers list in response to Mike Craddick regarding
18+
what motivated gyp's development, since we were aware of cmake at the time
19+
(we'd even started a speculative port):
20+
21+
22+
I did an exploratory port of portions of Chromium to cmake (I think I got as
23+
far as net, base, sandbox, and part of webkit).
24+
There were a number of motivations, not all of which would apply to other
25+
projects. Also, some of the design of gyp was informed by experience at
26+
Google with large projects built wholly from source, leading to features
27+
absent from cmake, but not strictly required for Chromium.
28+
29+
1. Ability to incrementally transition on Windows. It took us about 6 months
30+
to switch fully to gyp. Previous attempts to move to scons had taken a long
31+
time and failed, due to the requirement to transition while in flight. For a
32+
substantial period of time, we had a hybrid of checked in vcproj and gyp generated
33+
vcproj. To this day we still have a good number of GUIDs pinned in the gyp files,
34+
because different parts of our release pipeline have leftover assumptions
35+
regarding manipulating the raw sln/vcprojs. This transition occurred from
36+
the bottom up, largely because modules like base were easier to convert, and
37+
had a lower churn rate. During early stages of the transition, the majority
38+
of the team wasn't even aware they were using gyp, as it integrated into
39+
their existing workflow, and only affected modules that had been converted.
40+
41+
2. Generation of a more 'normal' vcproj file. Gyp attempts, particularly on
42+
Windows, to generate vcprojs which resemble hand generated projects. It
43+
doesn't generate any Makefile type projects, but instead produces msvs
44+
Custom Build Steps and Custom Build Rules. This makes the resulting projects
45+
easier to understand from the IDE and avoids parts of the IDE that simply
46+
don't function correctly if you use Makefile projects. Our early hope with
47+
gyp was to support the least common denominator of features present in each
48+
of the platform specific project file formats, rather than falling back on
49+
generated Makefiles/shell scripts to emulate some common abstraction. CMake by
50+
comparison makes a good faith attempt to use native project features, but
51+
falls back on generated scripts in order to preserve the same semantics on
52+
each platforms.
53+
54+
3. Abstraction on the level of project settings, rather than command line
55+
flags. In gyp's syntax you can add nearly any option present in a hand
56+
generated xcode/vcproj file. This allows you to use abstractions built into
57+
the IDEs rather than reverse engineering them possibly incorrectly for
58+
things like: manifest generation, precompiled headers, bundle generation.
59+
When somebody wants to use a particular menu option from msvs, I'm able to
60+
do a web search on the name of the setting from the IDE and provide them
61+
with a gyp stanza that does the equivalent. In many cases, not all project
62+
file constructs correspond to command line flags.
63+
64+
4. Strong notion of module public/private interface. Gyp allows targets to
65+
publish a set of direct_dependent_settings, specifying things like
66+
include_dirs, defines, platforms specific settings, etc. This means that
67+
when module A depends on module B, it automatically acquires the right build
68+
settings without module A being filled with assumptions/knowledge of exactly
69+
how module B is built. Additionally, all of the transitive dependencies of
70+
module B are pulled in. This avoids their being a single top level view of
71+
the project, rather each gyp file expresses knowledge about its immediate
72+
neighbors. This keep local knowledge local. CMake effectively has a large
73+
shared global namespace.
74+
75+
5. Cross platform generation. CMake is not able to generate all project
76+
files on all platforms. For example xcode projects cannot be generated from
77+
windows (cmake uses mac specific libraries to do project generation). This
78+
means that for instance generating a tarball containing pregenerated
79+
projects for all platforms is hard with Cmake (requires distribution to
80+
several machine types).
81+
82+
6. Gyp has rudimentary cross compile support. Currently we've added enough
83+
functionality to gyp to support x86 -> arm cross compiles. Last I checked
84+
this functionality wasn't present in cmake. (This occurred later).
85+
86+
87+
That being said there are a number of drawbacks currently to gyp:
88+
89+
1. Because platform specific settings are expressed at the project file
90+
level (rather than the command line level). Settings which might otherwise
91+
be shared in common between platforms (flags to gcc on mac/linux), end up
92+
being repeated twice. Though in fairness there is actually less sharing here
93+
than you'd think. include_dirs and defines actually represent 90% of what
94+
can be typically shared.
95+
96+
2. CMake may be more mature, having been applied to a broader range of
97+
projects. There a number of 'tool modules' for cmake, which are shared in a
98+
common community.
99+
100+
3. gyp currently makes some nasty assumptions about the availability of
101+
chromium's hermetic copy of cygwin on windows. This causes you to either
102+
have to special case a number of rules, or swallow this copy of cygwin as a
103+
build time dependency.
104+
105+
4. CMake includes a fairly readable imperative language. Currently Gyp has a
106+
somewhat poorly specified declarative language (variable expansion happens
107+
in sometimes weird and counter-intuitive ways). In fairness though, gyp assumes
108+
that external python scripts can be used as an escape hatch. Also gyp avoids
109+
a lot of the things you'd need imperative code for, by having a nice target
110+
settings publication mechanism.
111+
112+
5. (Feature/drawback depending on personal preference). Gyp's syntax is
113+
DEEPLY nested. It suffers from all of Lisp's advantages and drawbacks.
114+
115+
-BradN
116+
```

‎tools/gyp/docs/Hacking.md‎

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
# Hacking
2+
3+
## Getting the sources
4+
5+
Git is required to hack on anything, you can set up a git clone of GYP
6+
as follows:
7+
8+
```
9+
mkdir foo
10+
cd foo
11+
git clone git@github.com:nodejs/gyp-next.git
12+
cd gyp
13+
```
14+
15+
(this will clone gyp underneath it into `foo/gyp`.
16+
`foo` can be any directory name you want. Once you've done that,
17+
you can use the repo like anything other Git repo.
18+
19+
## Testing your change
20+
21+
GYP has a suite of tests which you can run with the provided test driver
22+
to make sure your changes aren't breaking anything important.
23+
24+
You run the test driver with e.g.
25+
26+
``` sh
27+
$ python -m pip install --upgrade pip setuptools
28+
$ pip install --editable ".[dev]"
29+
$ python -m pytest
30+
```
31+
32+
See [Testing](Testing.md) for more details on the test framework.
33+
34+
Note that it can be handy to look at the project files output by the tests
35+
to diagnose problems. The easiest way to do that is by kindly asking the
36+
test driver to leave the temporary directories it creates in-place.
37+
This is done by setting the enviroment variable "PRESERVE", e.g.
38+
39+
```
40+
set PRESERVE=all # On Windows
41+
export PRESERVE=all # On saner platforms.
42+
```
43+
44+
## Reviewing your change
45+
46+
All changes to GYP must be code reviewed before submission.

0 commit comments

Comments
 (0)
Back | FazBrowse Home | New Git URL