Re: [jamboost] Question on patch

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-18 20:50:40

----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Tuesday, December 18, 2001 6:21 PM
Subject: Re: [jamboost] Question on patch

> Dave,
>
> Sorry for the delayed response, I'm in the middle of takling Win32 & cross
DLL
> memory problems :-(
>
> On 2001-12-18 at 03:19 PM, david.abrahams_at_[hidden] (David Abrahams) wrote:
>
> >Why did you comment out these lines in gcc-stlport-tools.jam?
> >
> ># STDHDRS = ;
> ># STDLIBPATH = ;
> >
> >The point was that whatever was given by the gcc toolset should be
replaced
> >by what we calculate in this toolset. This could be important in the case
of
> >stlport, since the stlport paths must precede the system-supplied paths.
The
> >flags rule might otherwise just tack the new STDHDRS values onto the end
of
> >the existing list.
>
> Those lines where reseting the values AFTER they where set by the
<sysinclude>
> use.

That's intentional. You just do it again the stlport toolset:

flags gcc-stlport STDHDRS : $(STLPORT_ROOT)$(SLASH)stlport
$(GCC_INCLUDE_DIRECTORY) ;
flags gcc-stlport STDHDRS : <sysinclude> ;

> Which is why I changed the GCC tools to put the includes in the system
> path "-isystem" which places them before any defaults of the compiler.

In that case, do you still want $(GCC_INCLUDE_DIRECTORY) in there?

> Unfortunately I only have GCC on Linux to test this with so I don't know
> wether this works in the other GCC installations :-( And at least for me
(on
> Linux) the GCC_INCLUDE_DIRECTORY and GCC_STDLIB_DIRECTORY are always
empty.

Here's a test to try: install some other gcc in /usr/local/gcc-<version>.
Then set GCC_ROOT_DIRECTORY to point to that directory and try to build with
the newly-installed compiler.

> I'll try and see if I can make both of them work together, probably using
a
> different variable that the other tools use, like
STLPORT_INCLUDE_DIRECTORY
> and STLPORT_STDLIB_DIRECTORY.
>
> >You added "lib" to the beginning of the library name for gcc-stlport to
> >find. I'm pretty sure that won't work, since the -l option automatically
> >prepends "lib". So there would have to be a library called
> >"liblibstlport_<version>.a". Did you test this change?
>
> Hmmm, don't know why I did that... I don't even remeber doing that change
:-\
> I know I changed the literal version number that was on the dynamic
version
> because to me it made more sense to point to the symbolic link instead of
the
> specific version. Which thinking about it would cause problems with
stlport
> system that don't generate the symlink during the build. So that change
would
> also not work on non-*nix types like Windows with GCC.
>
> Which begs the question, which I saw someplace else, probably in the
TODOs, of
> better support for stlport than using the tools approach. Because as it is
it
> will never work for everyone :-(

Check out the Wiki material at
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build,
in particular
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build_D
esign_Proposal shows a way of addressing that question. It's a bit
disorganized, but I'm going to try to consolidate everything into a single
document before the year ends.

-Dave