[boost] Re: VC7.1 general question, idea for library builds

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-23 09:02:05

Chris Smith <smitty_one_each_at_[hidden]> writes:

> 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?  

That shouldn't be neccessary.  Building bjam works fine for me with a
standard vc7.1 installation:

C:\boost\tools\build\jam_src>build.bat
Setting environment for using Microsoft Visual Studio .NET 2003 tools.
(If you have another version of Visual Studio or Visual C++ installed and wish
to use its tools from the command line, run vcvars32.bat for that version.)
###
### Using 'vc7' toolset.
###

C:\boost\tools\build\jam_src>rd /S /Q bootstrap.vc7

C:\boost\tools\build\jam_src>md bootstrap.vc7

C:\boost\tools\build\jam_src>cl /nologo /GZ /Zi /MLd -DNT -DYYDEBUG kernel32.lib
 /Febootstrap.vc7\jam0  command.c compile.c execnt.c execunix.c execvms.c expand
.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c ja
m.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathuni
x.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c mo
dules.c strings.c filesys.c builtins.c pwd.c class.c
command.c
compile.c
execnt.c
execunix.c
execvms.c
expand.c
filent.c
fileos2.c
fileunix.c
filevms.c
glob.c
hash.c
hdrmacro.c
headers.c
jam.c
jambase.c
jamgram.c
lists.c
make.c
make1.c
Generating Code...
Compiling...
newstr.c
option.c
parse.c
pathunix.c
pathvms.c
regexp.c
rules.c
scan.c
search.c
subst.c
timestamp.c
variable.c
modules.c
strings.c
filesys.c
builtins.c
pwd.c
class.c
Generating Code...

C:\boost\tools\build\jam_src>.\bootstrap.vc7\jam0 -f build.jam --toolset=vc7 "--
toolset-root=C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\ " clean
...found 1 target...
...updating 1 target...
.rm. clean
...updated 1 target...

C:\boost\tools\build\jam_src>.\bootstrap.vc7\jam0 -f build.jam --toolset=vc7 "--
toolset-root=C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\ "

...found 74 targets...
...updating 4 targets...
.cc. bin.ntx86\yyacc.exe
yyacc.c
.cc. bin.ntx86\mkjambase.exe
mkjambase.c
.cc. bin.ntx86\jam.exe
command.c
compile.c
expand.c
glob.c
hash.c
hcache.c
headers.c
hdrmacro.c
jam.c
jambase.c
jamgram.c
lists.c
make.c
make1.c
newstr.c
option.c
parse.c
regexp.c
rules.c
scan.c
Generating Code...
Compiling...
search.c
subst.c
timestamp.c
variable.c
modules.c
strings.c
filesys.c
builtins.c
pwd.c
class.c
execnt.c
filent.c
pathunix.c
Generating Code...
.link. bin.ntx86\bjam.exe
        1 file(s) copied.
...updated 4 targets...
C:\boost\tools\build\jam_src>

> Looking at what got built, the static .libs made it, but no .dlls.

You must mean that you tried to build BOOST *using* bjam, no?  bjam
itself isn't supposed to include any .dlls.  Please post the precise
sequence of commands you used and the complete output.

> 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).

This stuff is being actively considered and discussed on the jamboost
list (see http://www.boost.org/more/mailing_lists.htm).  If you want
to participate, please join us there.

>    I think boost is the future of C++.  Thanks.

:^)   (^:

Akbar and Jeff love to hear that.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com