The current WiX project files do some manual processing and generation
which WiX supports doing out of the box. This patch will use the
HeatDirectory task to generate the npm.wxs file and use the auto GUID
generation. I also changed the msi filename generation to include the
version number to match the currently used name for released msi files.
Closes#3360
The v8 team apparently decided that all build products should go
into ./build/«type», and updated their common.gypi file to do so.
Unfortunately v8's common.gypi is only used for some targets. All
the other targets would still look in the old place to find their
their dependencies, which effectively broke the build.
In the long run it would be good for node to send all build
output to ./build too, on all platforms.
The old error handling code checked if the return value of Socket::Send() != 0,
which is wrong because Socket::Send() can write less bytes than requested or
return -1 on error.
* Update nodemsi.sln and .wixproj to include support for x64 platform
- Add ProgramFilesFolderId to the DefineConstants property for each
configuration/platform's property group with the appropriate value
(ProgramFilesFolder for x86 builds, ProgramFiles64Folder for x64
builds)
* Update product.wxs:
- update the Id value for the "Program Files" Directory element to
use a preprocessor constant.
- remove hard-coded platform from the Package element. MSI platform
will be automatically detected based on MSBuild's Platform property.
(This was already supported in the Wix MSBuild targets, we just
weren't taking advantage of it.)
* Update vcbuild.bat to set MSBuild's Platform property appropriately,
defaulting to x86 if not explicitly supplied by the user. Note that
creating an x64 build requires that vcbuild.bat be run from a VS
64-bit command prompt.
Closes#3312Closes#3356
In case a fd option is given to fs.createReadStream a read will instantly
happen. But in the edge case where fd point to an empty file and .pause()
was executed instantly, the end event would emit since no async wait was
between fs.createReadStream and the file read there emits end.
This is a cherry-pick of commit 1f3e4a7 into the v0.6 branch.
The server 'close' event was emitted before the last client 'close' event. Not
exactly fatal but potentially confusing.
Before this commit the order looked something like [client, server, client],
now it looks like [client, client, server].
See #3340 for more details.
In case a fd option is given to fs.createReadStream a read will instantly
happen. But in the edge case where fd point to an empty file and .pause()
was executed instantly, the end event would emit since no async wait was
between fs.createReadStream and the file read there emits end.
Said test relies a great deal on internals and implementation details (I should
know, I wrote it). Patch it up to work with libuv's new refcounting scheme.