Boost logo

Boost-Build :

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-11-06 19:27:40


[2002-11-06] David Abrahams wrote:

>Rene Rivera <grafik666_at_[hidden]> writes:
>
>> [2002-11-06] David Abrahams wrote:
>>
>>>And why would developers _have_ to use anything different from normal
>>>users?
>>
>> This is the difference you mentioned earlier... users do a
build-to-install,
>> while developers do a build-to-develop. The bootstrap scripts: build.sh,
and
>> build.bat take care of the build-to-install, whereas direct use of
build.jam
>> does the build-to-develop.
>>
>> -- Or am I misunderstanding your question?
>
>I think so.
>
>Suppose I change some of the bjam sources, but not the grammar. Is
>there some reason the build-to-install procedure is inappropriate for
>me?

Ahh, I see... There really isn't big reason why you couldn't use the
build-to-install procedure. But it does have some drawbacks for development
of bjam...

* There would be no way to build debug version instead of the optimized
release version. I'll be adding a --debug option to the build.jam. I could
add an equivalent option to the build.sh and build.bat scripts, but I think
that just adds more complexity that's not really needed.

* It will always re-build the bootstrap jam0. Instead of just the final
bin.*/bjam. I'm assuming here that a developer would already have
bootstraped beforehand.

Question is... Do you think we should simplify the build-to-develop
procedure also?

* For example we could make changes to Jambase to check for the build.jam
and use that. Eliminating the need for the "-f build.jam".

* I could also change build.jam to accept something like "--toolset-gcc"
instead of the longer "-sBOOST_JAM_TOOLSET=gcc".

Those two changes would make the build-to-develop command:

bjam/jam0 --toolset-gcc <options/targets>

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

 


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