Re: [boost] jam build problems

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-08-13 08:14:52

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

> >What command-line args are you using?
> >Normally, Jam only blurts the contents of the build commands if you
use -n
> >or -d+2.
>
> -sTOOLS=msvc
>
> >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.
>
> Doesn't seem to make any difference - that's why I wanted to build under
> cygwin.

Oh, I see. It makes no difference precisely /because/ Jam commands are
invoked through .bat files.

> >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).
>
> OK, but I'm running under win98 here - hence the problems I suspect.  I
had
> hoped that using cygwin would produce a more reliable system.

Hmm, I'm not sure why that's the case, unless Win98 is not being lumped
together with NT in Jam's config. I think the line length limitation you're
seeing is an artificial one. You could try editing rebuilding Jam after
editing jam.h. The key thing is to change the definition of MAXLINE for your
OS.

> >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.
>
> Using this on a per-toolset basis would be useful though wouldn't it?  BTW
> Borland also supports the @filename option.

It's not useful for anyone interested in writing truly portable Jamfiles,
but I guess not everyone falls into that category. Don't you want your
project to build with Cygwin/g++?

> >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.
>
> Yikes, does that work on unix like systems as well?

Why wouldn't it? This arrangement seemed to raise alarm bells for Bill as
well, but I can't understand why. A static lib is just an archive of object
files. If you compile them with the right options, there's no reason they
can't be part of a shared lib.

> >> 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?
>
> I tweeked the Jamfile and the problem went away, that's good enough for me
> for now, although the problem was reproducable on other platforms (or BeOS
> anyway).

Can you send me the Jamfile? Infinite recursion in the Jam code will cause
Jam to crash, FWIW.

> >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.
>
> But I guess not recently?

I guess not.

> >I've been doing cygwin builds from the NT shell using Jam very
> successfully,
> >and it's the route I suggest you try.
>
> Except as noted libraries don't build correctly - or at least they get the
> wrong extension...

They build correctly but don't get your preferred extension. There's no
reason you can't use those libs by putting them in the link line explicitly;
it's just that you can't use -lfoo to get libfoo.lib (at least I think you
can't). I agree that it's an unpleasant limitation but I don't think it's
too serious for the time being.

Regards,
Dave