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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-17 04:41:57

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-tar
>get-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.

I'm getting more unhappy about this stuff. The generated headers use-case is 
causing quite a lot of overhead for more common use cases, and deserves some
fixing (btw, this will also cut done header scanning time at least by half). 

But I need to think more, especially because I have a project which uses 
generated headers. So far, I'm leaning towards <uses-headers> features,
which will name main target to grab generated headers from. This won't
impose any overhead on ordinary main targets. Will think about details
in the subway this evening.

For now, I've comitted a workaround, which might reduce the number of
extra paths considerably.

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

Excellent. In fact, the testing you do is a very good help already, but some 
coding will be even better.

> > 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.

That will be simple. Good.

> > 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.

Both are possible, of course. I think it's up to you to decide what is best.

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

I've meant that in case of stlport, you can get the functionality you need 
quite easily -- you'd only have to declare a rule and call it in proper place.
When you have the time to actually do this, I can give more details/help, as 
needed.

- Volodya