Re: [jamboost] Re: [Boost-install] Some Recent Thoughts on Boost Installation

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
> >I'd
> >> like to see what others think. In order to minimize the number of
> >> compilations going on I made things so that it only generates
(compiles)
> >> specific *.o files once and they get reused when linking additional
> >targets
> >> 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
compile
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
huh?

> 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
> >get
> >> 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
> >linked.
> >>
> >> Question is... how severe of a problem would it be to disable that
> >feature
> >> 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.
Otherwise I
> get errors because the files disappear the second time a library is
> archived.

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
> >until
> >> absolutely possible. May take me a day just to figure out how to do
that.
> >
> >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
building
> them would require user intervention and then users would both specify
the
> 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
set
> the KEEPOBJS flag temporaryly so that its dependent targets don't delete
the
> objects.

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