From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-09-28 17:23:21
From: "Rene Rivera" <grafik666_at_[hidden]>
> [2002-09-28] David Abrahams wrote:
> >From: "Rene Rivera" <grafik666_at_[hidden]>
> >> OK, I have the solution implemented... mostly. I have one problem that
> >> like to see what others think. In order to minimize the number of
> >> compilations going on I made things so that it only generates
> >> specific *.o files once and they get reused when linking additional
> >> with different (un)tagged names.
> >I wouldn't go overboard with this. The build-to-develop and
> >build-to-install audiences are mostly distinct, and where they overlap,
> >waiting for another build is not too terrible... for now.
> Unfortunately those two audiences are undistinct currently in BBV1.
I don't understand. Once you stage some targets they don't function within
the build system, do they? IOW, there's no way to specify a dependency on a
"staged" version of a library, is there?
> I just
> did the work of checking to compiler *.o files once because it would
> the same files twice to the same target *.o file. Which seemed pointless,
> and keeping it the way it is would not solve the library archive problem
> anyway :-(
I'm utterly confused by your whole statement above, except that I
understand building the same *.o file twice seems pointless.
> >> But this creates problems with library
> >> targets because those mark the *.o files as TEMPORARY. This makes them
> >> deleted immidiately after the library is built,
> >No, TEMPORARY just affects the way dependencies are calculated. It's
> >RmTemps that makes them get deleted.
> Hmm, OK, but the only thing RmTemps rule does is mark them TEMPORARY. So
> it's the RmTemps actions I would have to change?
Yeah, but no need to change because of KEEPOBJS
> >> and therefore not available
> >> when another library archive, with a different (un)tagged name, is
> >> Question is... how severe of a problem would it be to disable that
> >> so that *.o files stay around always?
> >I don't think it's very severe; there's a variable which does it.
> And it works flawlessly, on my RH73 system, when I set the flag.
> get errors because the files disappear the second time a library is
Then maybe your platform should have NOARSCAN, or maybe your toolset is not
doing the scanning? Those two items need to be consistent.
> >> Disabling it means that I can get this totally done and fixed in a few
> >> minutes.
> >> Keeping it means figuring out how to make those things not disappear
> >> absolutely possible. May take me a day just to figure out how to do
> >I'd consider just telling people who overlap both audiences to set
> >KEEPOBJS, which will suppress RmTemps.
> As I said above... currently the two are one :-( For example any use of
> stage in the current Boost libs will fail because of this. This is true
> currently for regex which has a stage target.
Because you're now re-linking the libs in lieu of just copying them? Makes
sense; that's what's needed.
> An alternative is to make stage targets suppressed by default. So
> them would require user intervention and then users would both specify
> stage target to build and the -sKEEPOBJS=x flag.
Yeah. Or you could inspect the command-line to see if stage is specified
and add -sKEEPOBJS yourself.
> And another possibility, I'll have to try this, is to make stage targets
> the KEEPOBJS flag temporaryly so that its dependent targets don't delete
Depends on deferring RmTemps until after the last target depending on the
.o files is done. Tricky to get right.
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com
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