Re: [jamboost] [V2] Path resolution on win32

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

-----BEGIN PGP SIGNED MESSAGE-----
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...
gcc.compile 
pe/bin/gcc/release/debug-symbols-on/stdlib-stlport/threading-multi/main-target-pe/pe.o
g++: installation problem, cannot exec 
`/opt/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/cc1plus': 
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 
possible.

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

Yours, 

Jürgen

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

iD8DBQE+dZKLljbJ/LLrxrYRAiStAJ9DC/DlNx0ZtvF6JCHP6xtWB1jp/ACgud40
Xg1ykxRz59+M4BqszFt29DU=
=yrSv
-----END PGP SIGNATURE-----