This puts Meteor back on the official release track of Node.js 4, rather
than using its own custom build (from https://github.com/meteor/node/),
which had previously been necessary to add the garbage collection fixes
gained with
751f1ac08e
and
71f9cdf241,
both of which are now officially included in Node.js 4.x as of 4.8.6.
🎉
Even with $ErrorActionPreference, PowerShell won't automatically fail
when an external command fails with an error code. This explicitly
checks those exit codes and throws an error when that occurs.
Hopefully prevents false successes like that shown in this AppVeyor
test run: https://goo.gl/xxRsF9.
Though it was thought to be reliable when running through 'self-test' on
Windows, it's yet to be seen how reliable.
The worst thing that could come of adding Windows testing would be that
we have test failures again after such a string of green checkmarks and
confidence.
Also, reordered.
This implements a first generation of Windows CI testing. Presently,
this only runs valuable, hand-picked tests which have been known to work
in the past, and whose failure would indicate a critical problem.
A test which isn't passing doesn't mean that the feature being tested is
not working. For example, the 'create' test fails ostentatiously,
though the 'meteor create' command certainly works in practice. This
points to problems some compatibility problems with the 'self-test'
harness itself, some of which I'm aware of. Though, it likely will
highlight some legitimate problems which Windows users experience too.
There are a number of additional tests which should be enabled which
likely pass already, and many more which are failing and we should fix.
Additional tests can be added to the scripts/windows/appveyor/test.ps1
file as they've been deemed working.
Altogether, this will take extensive work to achieve the same level of
coverage our Unix test suite enjoy, but we've got to start somewhere!
cc @benjamn
While the actual version included for Unix developers will be our own
build at NODE_VERSION, this is important for the Windows version, since
it is not being rebuilt by our Jenkins at the moment.
Thanks to changes in the `build-node-for-dev-bundle.sh` script done in
0583e5883c, we now build a tarball which
is identical to the structure provided by Node.js themselves.
While generally we are using the main Node releases, this will allow
our users to (if need be), use a tarball directly in place of their own
in production without additional changes. Similarly, the only change
we need to make now when building the dev bundle is to use a different
URL.
In an effort to maintain parity with the official Node.js build, which
sets `node_prefix` to `/`, this takes advantage of the `DESTDIR`
variable which changes the actual installation location used by
`make install`. Without this, it relies on the `PREFIX` which is now
explicitly set to `/`, even though it won't be installed there.
See the `install.py` script for more information, in the form of code:
2a97eb61c6/tools/install.py (L13)
/cc @benjamn
To remain the same as official Node.js releases, we need to build with
the `small-icu` ICU (International Components for Unicode) package.
For Node.js 4.x this means ICU 56.x. As found with `process.config` on
an official Node.js release.
See https://github.com/nodejs/node/wiki/Intl#configure-node-with-specific-icu-source.
