From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-03-17 10:24:04
Vladimir Prus wrote:
> > > > 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.
Ah..I see I'm not the only one having this problem!
What was your workaround?
There are at least two things which I saw could be done
(1) remove the duplicates
(2) shorten the pathnames
(a) use relative pathnames
(b) cd to the directory where the input files are before running
I will do an update for your work-around and see if that fixes my
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk