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

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-09-28 17:26:37

[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 just
did the work of checking to compiler *.o files once because it would compile
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 :-(

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

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

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

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.

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.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]