The Windows 64-bit support is believed to be important enough to be
included in Meteor 1.6 since it fixes Meteor 1.6 issues on Windows.
While the original reason for 64-bit may have been Mongo, we'll leave
this as the 3.2.15 (but 64-bit!) version for now.
This commit reverts much of the work @hwillson had put in place for
meteor/meteor#9173, which made it possible for 32-bit and 64-bit
Mongo versions to exist in harmony within the same dev-bundle. That
hard work was not in vein though as it offered invaluable research.
Ultimately, this showed that a more aggressive approach would be ideal,
even if the proposed option would have worked great in the short-term.
In the wake of the news that Mongo would no longer be supporting 32-bit
versions, these changes are important so 32-bit users of Meteor can
continue to have a functioning Mongo binary in development, while still
allowing Meteor to ship newer Mongo (e.g. 3.4+) binaries for 64-bit
users. This is particularly relevant for Windows users, who have
previously only had 32-bit Meteor builds and represented a majority of
"32-bit" development, despite the fact most of their hosts supported
64-bit. During another time in Meteor's life, this made sense.
This commit takes improved functionality to the next level (and makes
the aforementioned changes obsolete) by introducing support for building
and shipping Meteor for Windows in a 64-bit flavor (in addition to
32-bit), which will hopefully solve a number of performance matters on
Windows by using binaries which are pre-compiled for 64-bit, rather than
forcing the Windows kernel to deal with 32-bit binaries. While Windows
has shown it's quite capable of dealing with such a situation, it seems
more and more clear (given improvements in underlying dependencies) that
performance gains could be had by freeing Windows of its 32-bit work.
This commit also further perpetuates the "archinfo" plot-line with more
story (about Windows) and various spelling corrections.
If any part of the dev bundle generation fails, the script should stop.
I was encountering a barely-noticed failure in the Python extraction
when the download tarball was 404-ing (due to my own fault), but the
script proceeded as if the failure hadn't happened, resulting in a
broken dev bundle.
These changes introduce dual Mongo support into the Meteor
Tool. 32-bit Mongo (3.2.15) will be used by Meteor when the
Tool is run on a 32-bit OS (32-bit Linux and Windows). 64-bit
Mongo (3.4.9) will be used when the Tool is run on a 64-bit
OS (64-bit Linux, Windows and macOS).
Fixes https://github.com/meteor/meteor-feature-requests/issues/129.
This was accomplished in 67b76abc78 by
@benjamn, but a merge commit from devel to release-1.6 inadvertently
removed half of it. Prior to this commit, the new headers have been
used, but the old headers were still in place and taking up room.
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.
