search

nodejitsu / module-foundry

A web service for building node.js modules that runs on Linux, SmartOS and Windows.
MIT License
80 stars 8 forks source link

Windows SDK & Tools section seems wrong #21

Closed nschonni closed 9 years ago

nschonni commented 10 years ago

Not sure if the instructions were a meld of a few blog posts on setting up chocalety.

indexzero commented 10 years ago

@dch Thoughts on this?

glennblock commented 10 years ago

Isn't node-gyp installed by default with node now? Why does it need to be installed?

BTW @nschonni the work you did looks very cool!

nschonni commented 10 years ago

Isn't node-gyp installed by default with node now? Why does it need to be installed?

I believe your mostly right, except that node-gyp has dependencies (like Python, VS2010, Windows SDK, etc...) that don't ship with NPM.

BTW @nschonni the work you did looks very cool!

Thanks! I wanted to help out on the Azure SDKs, but the CLA was a non-starter given my employer.

glennblock commented 10 years ago

@nschonni Aaah so you mean making sure the installation of the dependencies is documented.

Sorry that the CLA blocked you, that does suck.

nschonni commented 10 years ago

Yeah, the https://github.com/nodejitsu/module-foundry/blob/master/scripts/setup-node-gyp.sh will work in Git Bash on Windows.

There is also a difference of dependencies between SmartOS, Ubuntu, and Windows. If there is a base list of expected dependencies, then an equivalent Chocolatey script can be provided.

glennblock commented 10 years ago

Make sense. Looking at it though an idea would be having one module-foundry Chocolatey script that pulls in the dependencies.

It would be nice for someone to just do "cinst module-foundry" and get everything INCLUDING Python which is also avail on Chocolatey.

I wouldn't include necessary VS in this, but you can get by with VS Express which should also be indicated int he docs.

nschonni commented 10 years ago

I think VS Express is also available on Chocolatey

glennblock commented 10 years ago

Looks like it: http://chocolatey.org/packages/VisualStudioExpress2013WindowsDesktop

glennblock commented 10 years ago

Though you would want it to be optional and not install if VS was already present.

dch commented 10 years ago

TL;DR @nschonni practically speaking, has this approach broken anything for you, or failed to build something that should work under node-gyp?

The original instructions in the windows.md file were done for building CI-style automated build slaves IIRC a year or more ago, based off the node-gyp requirements at the time, and to support older node releases (0.6 and 0.8) as well as the upcoming 0.10 series. If you're not doing this parallel build work across multiple node releases, you can definitely keep things simpler & just use the node-gyp requirements. We can make this (more) clear in the docs.

Some notes on why things are there:

@glennblock +1 for a "cinst module-foundry" script good call. Would you expect that to work OOTB on a vanilla install, or to play nice with whatever's already there?

Overall the main issue is that every Windows SDK, Visual Studio bundle & release, all bring significant tool chain changes, and are in general often don't play nice with multiple installed versions. This makes building modules for windows a tricky task. There are countless examples of broken compiler/SDK versions and hacks to address them.. The SDK 7.1 is free, relatively self-contained, and has significantly fewer hotfixes and security updates compared to Visual Studio. It can mostly be installed side-by-side with other SDKs and VS versions. The alternative is to ask somebody with Visual Studio to install VS Express which may very likely break their VS install. If after testing a matrix of SDK installs & Visual Studio installs you have a better suggestion, I'm all ears -- making this simpler would be fantastic.

Personally, I recommend having a baseline config, that includes the minimum GUI requirements, on a separate build VM or instance. And if you need rich debugging by all means install VS but bear in mind that bits will break. So yes, I have a separate VM with Visual Studio on it too. Sadly I've not found any reliable alternative.

Finally, I'm looking forwards to being able to use clang/llvm directly on Windows in future.

nschonni commented 10 years ago

TL;DR @nschonni practically speaking, has this approach broken anything for you, or failed to build something that should work under node-gyp?

Chocolatey blows up behind a corporate proxy so I'm try to separate out what is actually required at all. I do node-gyp builds for node-sass with much less dependencies than this, so I'm trying to figure out what bits are required for module-foundry.

running a Windows box mandates some security scanner, BYO is fine obviously

Agreed, but it doesn't really relate to setting up a module-foundry build box

aria2 because it's the easiest way to provide a single file of URLs to download into a directory to bootstrap the toolkit

This isn't actually used anywhere

mozilla tools as it's a well tested and maintained package of unixy tools for windows that doesn't install cruft elsewhere in the system. Obviously you can install git, emacs, vi, your preferred shell etc separately, but then the surface area to mantain is much larger & it's harder for a dev to replicate your failing issue on a consistent/clean box

Looking at the list https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Windows_Prerequisites#MozillaBuild it seems like Python and autconf are the only pieces that might relate to a node-gyp build. You're right that using this package adds the VCC 2008 SP1 dependency.

Finally, I'm looking forwards to being able to use clang/llvm directly on Windows in future.

:+1: I've been playing around with clang on Windows this week, but I haven't tried any of the beta Visual Studio integration

glennblock commented 10 years ago

Hi Dave

I would settle for a chocolatey script that you can use on a vanilla box and it gets everything setup. It would be nice to be able to support detecting existing tools, but that would be a ton of work.

Having the vanilla script would give me a very easy way to get a VM up and running.

On Tue, Jan 14, 2014 at 6:41 AM, Dave Cottlehuber notifications@github.comwrote:

TL;DR @nschonni https://github.com/nschonni practically speaking, has this apporach broken anything for you, or failed to build something that should work under node-gyp?

The original instructions in the windows.md file were done for building CI-style automated build slaves IIRC a year or more ago, based off the node-gyp requirements at the time, and to support older node releases (0.6 and 0.8) as well as the upcoming 0.10 series. If you're not doing this parallel build work across multiple node releases, you can definitely keep things simpler & just use the node-gyp requirements. We can make this (more) clear in the docs.

Some notes on why things are there:

  • running a Windows box mandates some security scanner, BYO is fine obviously
  • aria2 because it's the easiest way to provide a single file of URLs to download into a directory to bootstrap the toolkit
  • mozilla tools as it's a well tested and maintained package of unixy tools for windows that doesn't install cruft elsewhere in the system. Obviously you can install git, emacs, vi, your preferred shell etc separately, but then the surface area to mantain is much larger & it's harder for a dev to replicate your failing issue on a consistent/clean box
  • vcredist because the mozilla tools break without it (I forget exactly which bits)
  • ntrights.exe to open up some permissions to allow build bots to run with non-admin privileges
  • SDK 7.1 as if you are doing 64-bit builds you need it anyway, and it's the same compiler used by some of the VS 2010 versions.

@glennblock https://github.com/glennblock +1 for a "cinst module-foundry" script good call. Would you expect that to work OOTB on a vanilla install, or to play nice with whatever's already there?

Overall the main issue is that every Windows SDK, Visual Studio bundle & release, all bring significant tool chain changes, and are in general often don't play nice with multiple installed versions. This makes building modules for windows a tricky task. There are countless examples of broken compiler/SDK versions and hacks to address them.. The SDK 7.1 is free, relatively self-contained, and has significantly fewer hotfixes and security updates compared to Visual Studio. It can mostly be installed side-by-side with other SDKs and VS versions. The alternative is to ask somebody with Visual Studio to install VS Express which may very likely break their VS install. If after testing a matrix of SDK installs & Visual Studio installs you have a better suggestion, I'm all ears -- making this simpler would be fantastic.

Personally, I recommend having a baseline config, that includes the minimum GUI requirements, on a separate build VM or instance. And if you need rich debugging by all means install VS but bear in mind that bits will break. So yes, I have a separate VM with Visual Studio on it too. Sadly I've not found any reliable alternative.

Finally, I'm looking forwards to being able to use clang/llvm directly on Windows in future.

- http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html

— Reply to this email directly or view it on GitHubhttps://github.com/nodejitsu/module-foundry/issues/21#issuecomment-32269484 .