Repository navigation
Tests on Windows take forever to start #179
Description
Activity
@seishun I have no idea, the same issue is bugging me. A patch (or an explanation) would be very welcome.
Does src/node.js or the files in lib/ have timestamps in the future? Or maybe the generated node_natives.h ends up with a timestamp that is in the past somehow? That's the only thing I can think of.
I think I know what happens: vcbuild.bat re-generates the .sln/.vcxproj files which makes msbuild re-run the js2c "custom build step".
A workaround is to call
vcbuild noprojgen nosign test. A nicer solution I think would be to split the configuration and build steps into separate batch files, e.g.configure.batandmake.bat.Actually, config.gypi is the culprit here. Its modification date gets bumped during the project generation, and it's listed as an input to the node_js2c target. Now I'm trying to find answers to the following questions:
- What is the magic that prevents the .sln/.vcxproj files from getting re-generated if no change is required, and can we apply the same magic to config.gypi?
- Why is config.gypi even required for js2c?
Looks like config.gypi was added to the inputs in 95fd517. And there is no explanation. sigh
/cc @TooTallNate
@seishun It becomes the
process.configvariable:$ out/x64.release/node -p process.config { target_defaults: { cflags: [], default_configuration: 'Release', defines: [ 'OPENSSL_NO_SSL2=1' ], include_dirs: [], libraries: [] }, variables: { clang: 0, gcc_version: 49, host_arch: 'x64', icu_small: false, node_install_npm: true, node_prefix: '/home/bnoordhuis/opt/node', node_shared_http_parser: false, node_shared_libuv: false, node_shared_openssl: false, node_shared_v8: false, node_shared_zlib: false, node_tag: '', node_use_dtrace: false, node_use_etw: false, node_use_mdb: false, node_use_openssl: true, node_use_perfctr: false, openssl_no_asm: 0, python: '/usr/bin/python', target_arch: 'x64', uv_library: 'static_library', uv_parent_path: '/deps/uv/', uv_use_dtrace: false, v8_enable_gdbjit: 0, v8_enable_i18n_support: 0, v8_no_strict_aliasing: 1, v8_optimized_debug: 0, v8_random_seed: 0, v8_use_snapshot: true, want_separate_host_toolset: 0 } }I've found the magic! It's in WriteOnDiff for .sln files and WriteXmlIfChanged for .vcxproj files. Perhaps we could do something similar for config.gypi? Admittedly, it feels kinda hacky.
A nicer solution I think would be to split the configuration and build steps into separate batch files, e.g. configure.bat and make.bat.
I'm not sure how this would help. It would just shift the burden of deciding whether to regenerate project files to the user.
I've found the magic! It's in WriteOnDiff for .sln files and WriteXmlIfChanged for .vcxproj files. Perhaps we could do something similar for config.gypi? Admittedly, it feels kinda hacky.
So this is your chance to make a PR :)
I've discovered that Makefile errors if config.gypi is older than configure.py. If my understanding is correct, this means that if we add WriteOnDiff magic to configure.py, re-running it will not always fix the
makeerror. Sounds bad.This original issue doesn't affect Linux because it doesn't run configure.py when running
make. However, if the project structure (and thus node.gyp) has changed, the Makefile automatically runsgyp_node.py. That doesn't happen when building the VS solution (which is actually one of the selling points of gn - "GN supports automatically re-running itself as needed by Ninja as part of the build").I'm not sure how to fix this properly.
- added 2 commits that reference this issue
on Aug 3, 2017 - added a commit that references this issue
on Aug 13, 2017 - added a commit that references this issue
on Aug 14, 2017 - added a commit that references this issue
on May 28, 2024
For some reason, whenever I run
vcbuild test nosign, msbuild decides to rebuild node_javascript.cc and subsequently re-link node.lib, which for some reason takes several minutes on a Core i7 machine (many times longer than in Visual Studio). This behavior has been observed on two different machines.I'm going to attempt to figure out what's causing this and how to fix it, but perhaps someone can give me some pointers.
In case it matters, I'm using Visual Studio Express 2013 for Windows Desktop.
/cc @piscisaureus @rvagg