Re: [boost] jam build problems

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-08-12 07:46:00

----- Original Message -----
From: "John Maddock" <John_Maddock_at_[hidden]>
To: "boost" <boost_at_[hidden]>
Sent: Sunday, August 12, 2001 7:55 AM
Subject: [boost] jam build problems

> Dave,
>
> I've been trying to use the new build system to setup the regex lib, but
so
> far haven't got much beyond first base.
>
> With the prebuilt Win32 FTJam executable:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> OK, installation is no problem.
>
> I can build the regex lib as a static lib with msvc OK - but I see a lot
of
> spurious output at the end:

<snip>

What command-line args are you using?
Normally, Jam only blurts the contents of the build commands if you use -n
or -d+2.

> D:\boost\develop\boost>
>
> Note the apparent command.com command prompts here - I'm running this
under
> bash!

Yikes! Boost.Build wasn't designed to work that way. If you /must/ invoke
Jam from bash (cygwin?), you might consider investigating the JAMSHELL
variable in the Jam docs to see if you can set it to invoke the command
processor in a more reliable fashion.

> Trying to build the regex lib as a dll (see updated regex Jamfile) fails
> because the command line is longer than Jam's internal limit:
>
>    msvc-Link-action actions too long (max 996)!

You must not have the latest FTJam. He removed the limitation (now we just
have the built in NT .bat file limit of ~2K characters - Jam executes all
commands through .bat files).

> Now the regex lib doesn't have that many object files, and if this is
going
> to overflow the command line, we have a real problem.  The ideal solution
> is to use a command file: "cl @commands.txt", but that requires support
> from jam - does it support "here files" at all?

Jam itself supports anything you want ;-)

The build system isn't set up to do it. The problem with that approach, as I
was recently telling Bill Kempf, is that it will solve the problem for MSVC
but not for other compilers on Windows.

The workaround, if you end up running into the NT limit, is to build several
static libs that get linked into your DLL (and please trust me that this
works):

lib dll_part1 : source1.cpp source2.cpp ... ;
lib dll_part2 : source3.cpp source4.cpp ... ;
...
dll regex.dll : <lib>dll_part1 <lib>dll_part2 ... ;

I know it's ugly, but we don't know a more reliable way, yet.

> I then added a Jamfile to libs/regex/example/ with just one test example
so
> far - really just to see if I can link to the one library I did manage to
> build - unfortunately I get an access violation inside jam here, ouch.

Ooh! Can you produce a debugger stack backtrace?

> One final note, if I build with -sTOOLS=gcc then cygwin creates
> libboost_regex.lib - shouldn't that be libboost_regex.a ??

I guess so. Oof, making file extension choices dependent on toolset is a big
fork just to support cygwin. Except for Cygwin, there are a bunch of things
which are determined solely by the OS on which the build occurs. I guess
Cygwin really /needs/ forward slashes sometimes as well. I'll think about
it.

> Building the sources under Cywin:
> ~~~~~~~~~~~~~~~~~~~~~~
>
> As a workaround for the command line length problem I tried building the
> sources with cygwin, it took me a while to figure out that I had to edit
> the makefile and uncomment some cygwin specific defines, once I did that I
> at least got jam0.exe to build, but then it all goes horribly wrong,
here's
> what I see:
>
<snip>
>
> At which point I gave up.
>
> I also tried using the intermediate jam0.exe executable as jam with boost
> and that was really really bad (include paths completely screwed up), gave
> up again.
>
> Anyway I hope you have some insights into all this :-(
>

Well, it's clear to me from looking at the source code that somebody built
Jam under Cygwin once, but I'm not going to try it.

I've been doing cygwin builds from the NT shell using Jam very successfully,
and it's the route I suggest you try.

-Dave