From: Chris Smith (smitty_one_each_at_[hidden])
Date: 2003-10-22 13:02:10
Greetings,
1. Using boost for a while under Linux. Trying to build the CVS under
VC7.1 on WinXP.
After setting the appropriate environment variables, I tried to build
bjam using the .bat file.
Got:
LINK : fatal error LNK1181: cannot open input file 'C:\Program.obj'
Googling about, this seems to be brought on by space characters in the
file paths. If that's true, it's self-commenting. :-)
Is there a Best Practice? Should I re-install Visual Studio into a
concise, no-space path? Looking at what got built, the static .libs
made it, but no .dlls.
2. Also, has the following idea been kicked around for controlling the
builds:
Under boost/bin/boost/libs/, have a coded directory that 'flattens
out' the current branches into an acronym.
Acronym would decode as:
OS one char
compiler three or so
archive or shared one char
debug or release one char
debug level integer
For example, w_vc7_s_r would be a container for windows VC7 .dll
release versions.
l_gcc_a_d2 would hold linux gcc static archives with debug level two.
Any library that supports those characteristics would go in there,
date_time, filesystem, regex, and so on.
Some disadvantages are:
change
not as readily apparent to the user
need to consider carefully exactly what values to standardize upon.
(perceived) Advantages:
more granular (especially if you like multiple debug levels)
shorter paths
(potentially) smoother library installs
(possibly) cleaner jam files (I haven't written one yet, so I can't
say, but from some GNU make experience, it could help tidy things).
I think boost is the future of C++. Thanks.
R,
Chris