refack/gyp3

Generate You Projects

[a fork of the unmaintained google/GYP]

Generate You Projects

Documentation is available at http://gyp3.org/ (or at the gh-pages branch).

gyp3's Issues

adding compiler flag for windows / MSVC

to permit compiling umlaut chars like:

auto a = u'ü';

MSVC needs to be set the commandline switch

/UTF-8

I fail to work my way through the msbuild generator how I'd best achieve this; Anybody got a hint for me on this?

Could we get a release on PyPI?

https://pypi.org/user/arunadmin Seems to have been created and last updated over two years ago.

Would it be possible to use that PyPI name or a new PyPI name to get a new release on PyPI to simplify installation?

Travis CI: Fix the shellcheck linting issues..

Travis CI runs shellcheck on the *.sh files in our repo with results that currently look like this: https://travis-ci.com/refack/GYP/jobs/162734096#L379

Could someone please try to fix these issues?

Gyp demands relative paths of source but doesn't enforce it

to generate source file lines, gyp needs paths relative to the gypfile itself.
i.e. :

      'sources': [
        '<(V8_ROOT)/base/trace_event/common/trace_event_common.h',
        '<(V8_ROOT)/include/libplatform/libplatform-export.h',
        '<(V8_ROOT)/include/libplatform/libplatform.h',
        '<(V8_ROOT)/include/libplatform/v8-tracing.h',
        '<(V8_ROOT)/src/libplatform/default-foreground-task-runner.cc', ....
      ],

works as long as V8_ROOT is a relative path. If its absolute, the produced make file fails to trigger the compilation of these files:

OBJS := \
	$(obj).target/$(TARGET)//home/willi/src/devel/3rdParty/V8/v7.1.302.28/src/libplatform/default-foreground-task-runner.o \
	$(obj).target/$(TARGET)//home/willi/src/devel/3rdParty/V8/v7.1.302.28/src/libplatform/default-platform.o \
	$(obj).target/$(TARGET)//home/willi/src/devel/3rdParty/V8/v7.1.302.28/src/libplatform/default-worker-threads-task-runner.o \

and make will error out when trying to link these files, that it doesn't know how to create them.

either this behaviour should be fixed, or gyp should error out on absolute files

test macos fix mutually exclusive flags

Write a test for this fix. Maybe something based on https://github.com/refack/GYP/blob/0e5171ac64f5241e1428f929474c246c2d226b28/test/mac/gyptest-deployment-target.py#L22

Originally posted by @refack in #42 (comment)

MOAR!!1 static analysis

expand https://github.com/refack/GYP/blob/9acfe76809586c952ce952eeec5a3f6445b0cc49/.flake8#L3
incrementally, to get maximum benefit from static analysis.

Travis CI: Windows command "nvs add" requires a version parameter

3.45s$ nvs add 
Downloading bootstrap node from https://nodejs.org/dist/v10.12.0/node-v10.12.0-win-x64.7z
######################################################################## 100.0%
The command "nvs add " failed and exited with 1 during .
Your build has been stopped.
A version parameter is required.

GYP generate bad end-of-line under Windows

GYP generate a bad end-of-line marker when used under Windows. Instead of CRLF, GYP generate CRCRLF (Double carriage return).

I see that thru libuv project which make use of GYP to generate MSVC2010 solution (vcbuild.bat invokes GYP). See https://github.com/libuv/libuv/issues/2299

Regards,
François Piette

Typos?

@XhmikosR Could you please do your typo check here too?

ARM64 Windows support needs tests

Now that support for ARM64 Windows ASM has been added, it should have accompanying tests.

See discussion here: #23

Merge upstream: cmp is an invalid sort() argument

we are currently running into the issue that

gyp\generator\xcodeproj_file.py", line 1414, in SortGroup
    sorted(self._properties['children'], cmp=lambda x,y: x.Compare(y))
TypeError: 'cmp' is an invalid keyword argument for sort()

Upstream had merged some small fixes recently, please merge at least https://chromium.googlesource.com/external/gyp/+/aca1e2c3d346d704adfa60944e6b4dd06f4728be

Thanks!

Travis CI: Windows builds are failing because 'dotnetfx' requires a reboot

https://travis-ci.com/refack/GYP3

Packages requiring reboot:
 - dotnetfx (exit code 3010)
The recent package changes indicate a reboot is necessary.
 Please reboot at your earliest convenience.
The command "choco install python3 visualstudio2019buildtools visualstudio2019-workload-vctools" failed and exited with 194 during .
Your build has been stopped.

Add default `knownRegions` key to silence a new Xcode 10.2 warning

What steps will reproduce the problem?

1. In Xcode 10.2, a new warning is shown for all gyp-generated projects stating: "Enable Base Internationalization"
2. This is because gyp has never generated the knownRegions key, and Xcode has always (previously) silently created it
3. Clicking to "fix" the warning in Xcode will auto-generate the knownRegions key, but any time an xcodeproj file is regenerated (and Xcode rebooted) the warning will yet again show and need to be "fixed"

What is the expected output? What do you see instead?

One would hope that gyp would auto-generate a default key, but

What version of the product are you using? On what operating system?

macOS Mojave 10.14.4 using an up-to-date GYP as of April 1, 2019

Please provide any additional information below.

The fix proposed for this ticket is to add the following line to xcodeproj_file.py somewhere after line 2582 (the "_schema.update" line):

 'knownRegions':           [0, list,                 0, 1, ['en', 'Base']],

This will silence the error and have the same effect of the "Xcode fix."

However, it would probably be a good idea to have a key from within gyp that the user could configure since one could imagine adding "more languages" to the knownRegions, as well as it already being possible to change this key from within Xcode itself (and not possible to do this within the gyp file currently.)

filename handling for MSVC

The v8 torque transpiler expects filenames relative to -v8-root. This seems to work on linux with makefile target - "<(V8_ROOT)/src/builtins/array.tq", will become ../src/builtins/array.tq - all good.
However, the msbuild generator tries to make this path absolute when its put through:

          'inputs': [  # Order matters.
            '<(PRODUCT_DIR)/<(EXECUTABLE_PREFIX)torque<(EXECUTABLE_SUFFIX)',
            '<@(torque_files)',
          ],

I failed to get any solution working which would give me a working run_torque target.

I ended up patching that stupid behaviour out of torque by improving the error message, and making it attempt to simply directly opening the path instead of running it through its own vodoo:

void ReadAndParseTorqueFile(const std::string& path) {
  SourceId source_id = SourceFileMap::AddSource(path);
  CurrentSourceFile::Scope source_id_scope(source_id);

  // path might be either a normal file path or an encoded URI.
  auto fn = SourceFileMap::AbsolutePath(source_id);
  auto maybe_content = ReadFile(fn);
  std::string maybe_path;
  if (!maybe_content) {
    if (auto mmmaybe_path = FileUriDecode(path)) {
      maybe_path = *mmmaybe_path;
      maybe_content = ReadFile(maybe_path);
    }
  }
  if (!maybe_content) {
    maybe_content = ReadFile(path);
  }
  if (!maybe_content) {
    std::string allPaths = path + " - " + fn + " - " + maybe_path;
    Error("Cannot open file path/uri: ", allPaths).Throw();
  }

  ParseTorque(*maybe_content);
}

whats the best way ahead here? Find a fix for gyp3? Propose the torque fix upstream (if yes - is there somebody willing to do it? I hereby put my changes into public domain) ?

Consider using vswhere to find Visual Studio installation

Right now the code in MSVSVersion.py uses the registry to find the Visual Studio installation.
I re-installed my windows 10 recently and only installed the latest copy of Visual Studio 2019, as it turns out none of the registry keys being checked exist on my machine.

I suggest checking for the default location of vswhere.exe and downloading it if it's not there, so we use that to find the Visual Studio installation.

Is this something that makes sense here, I would be happy to implement this and submit a PR.

filename prepended?

On this place:

https://github.com/nodejs/node/blob/master/tools/v8_gypfiles/v8.gyp#L463

it will generate --random-seed <some directory>31...
which will then only trigger a usage warning for mksnapshot.

Support ARM64 Windows dual-toolchain MSVC cross-compilation

The simplest cross-compilation scenario is compiling source on one architecture for another. Currently, MSVC and GYP both support this for ARM64--that is, MSVC provides x64-arm64 and x86-arm64 toolchains, while GYP supports generating MSVC projects that use either of these.

If the project requires compiling and then running tools (such as v8's mksnapshot during the Node.js build), then both the ARM64 and x64 toolchains need to be invoked during the build. MSVC partially supports this--each project can contain multiple configurations--but currently GYP only supports using one toolchain at a time. See https://github.com/refack/GYP/blob/master/pylib/gyp/generator/msvs.py#L1849

The simplest solution would be to support emitting projects with two toolchain configurations, then letting the user invoke msbuild twice with two configurations.

The ideal solution would be to use msbuild magic to emit projects such that msbuild need only be invoked once, but I don't know if this is possible.