jparris / enso

Automatically exported from code.google.com/p/enso
Other
0 stars 0 forks source link

Building on Windows needs some environment variables to work #12

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Build on Windows
2. See errors
3. Curse

This is mostly related to building with version of Visual Studio and
Platform SDK/Windows SDK that SCons doesn't support or doesn't detect
properly. But there are some other issues too.

Note that most of these fixes assume that Visual Studio has set the right
environment variables. Often, vcvarsall.bat needs to be run before hand.
And while these environment variables may exist, doesn't import any of them
unless you do it explicitly.

1. Linker sometimes needs a temp directory to write to
2. Compiler/linker paths not detected
3. Include/lib directories not always detected

Original issue reported on code.google.com by unfocu...@gmail.com on 22 Mar 2008 at 7:00

Attachments:

GoogleCodeExporter commented 8 years ago
If anything, I think this may ultimately need to be a patch to SCons.  The great
thing about SCons is that it's meant to auto-detect things like the location of 
MSVC
(by looking into the registry, etc) and as a result is meant to be entirely
independent of things like vcvarsall.bat and the configuration of special 
environment
variables.  

When I first ran into a similar problem a few years ago--I believe SCons wasn't
properly detecting my installation of MSVC++ Express Edition 2005--I ended up
submitting the fix as a patch to SCons, rather than hacking my SConstruct to get
things to work properly.

Original comment by var...@gmail.com on 24 Mar 2008 at 4:25

GoogleCodeExporter commented 8 years ago
Yea, I looked into patching SCons as well. There's nothing in the SCons SVN for
Visual Studio 2008 yet (http://scons.tigris.org/source/browse/scons/ ).

And unfortunately, the code for detecting Visual Studio is a huge mess of 
spaghetti
(thank you Microsoft...). All the registry entries for Visual Studio 2008 have
changed yet again, so it'll need all new detection code.

I'll have a look at the registry structure for VS2008 and post back my results 
here.
There's a small chance it may even be easier to detect VS2008 than earlier 
editions -
but I'm not holding my breath.

I'm quite willing to do the detection code myself, if I think I can get it done 
and
still have my sanity at the end of it.

Original comment by unfocu...@gmail.com on 25 Mar 2008 at 4:52

GoogleCodeExporter commented 8 years ago
Ok, I've had a look at the registry setup for VS 2008, and it doesn't seem all 
that
different from VS2005. So I *think* a lot of the existing detection code should 
work,
at least for detecting paths for the tools.

Platform SDK is now Microsoft SDKs - but detecting that is easy, as there's no
overrides to deal with. It appears to be just one registry key that points to 
the
current install directory, which is handy.

I'm mostly going off my local install here - and I left the install location as 
the
default, if I remember correctly. So take everything here with a grain of salt.

Original comment by unfocu...@gmail.com on 25 Mar 2008 at 5:59