Boost logo

Boost-Build :

From: Jürgen Hunold (hunold+lists.Boost_at_[hidden])
Date: 2003-03-17 04:16:59

Hash: SHA1

Hi Vladimir !

On Monday 17 March 2003 09:59, Vladimir Prus wrote:
> Hi Jürgen,
> > Ah, I see. I can live with these includes right now.

... I thought. V2 just blew up stating
..updating 4 targets...
g++: installation problem, cannot exec
Argument list too long

The argument list contains "hundreds" of generated include statements.
It would be great if you could address the generated include issue a
little bit sooner.

> > But I've got one other question:
> > The library names for both qt and stlport are hardcoded in qt.jam
> > and stlport.jam for gcc. For windows, I'd need different library
> > names, e.g stlport_cygwin for cygwin-gcc, stlport_win32 for msvc
> > and so on. Qt should even be mor problematic, because you've got
> > something along qt312.lib for Qt-3.1.2 on windows.
> >
> > Can you give me a hint when this will be addressed ?
> I don't know :-) I think that I'd need some help from you in doing
> it.

Well, I want to use V2, so I've got to help ;-))

> > Or how can I do something myself ?
> The first thing to determine is how those names are computed. Do
> they depend only on toolset? Or one should be able to configure
> them?
> The first case is pretty simple. One will introduce a new rule in
> 'stlport.jam', which will take a list of properties and return the
> library name.

Well, the library names for stlport are hardcoded in the stlport
makefiles for the specific compiler/platform combination. These could
be hardcoded, then.

> In the second case, the 'init' rule for stlport.jam should accept
> some additional parameters, and the rule returning the name should
> use them, too.

Well, this is the way for the qt toolset. There you should configure
the actual library name or deduce it from the qt path, if this is

For example, e:\Libraries\Qt\3.1.2 should result in qt312.lib or
qt-mt312.lib for multithreaded Qt.

> In either case, the complexity depends on how library names are
> determined -- there's little Boost.Build internals to fight with
> :-)

Well, I think I _really_ should get more familiar with thos internals



- --
* Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen,
* voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover
* fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover
* hunold_at_[hidden] !
Version: GnuPG v1.2.1 (GNU/Linux)



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at