|
Boost-Build : |
From: Rene Rivera (grafik.list_at_[hidden])
Date: 2006-03-26 10:56:28
Emil Dotchevski wrote:
> I second this message.
>
> Though I have no experience with v1, I also often find myself having to
> duplicate requirements and usage requirements, and this I agree is prone to
> errors.
>
> However, I think the concepts are different and should be kept separated; I
> think that the ideal solution would be if there was a way to write my own
> wrapper which duplicates them for me, however I don't know jam or bjam well
> enough to write this or even to tell whether it's possible or not... :|
You might want to try what I'm doing in some cases then...
> ----- Original Message -----
>> If it's not already possible to remove that duplication my suggestion
>> would be to:
>>
>> 1. Allow both kinds of requirements in the requirements section.
>>
>> 2. To tag requirements that are both regular requirements and
>> usage-requirements with <*>.
>>
>> For example:
>>
>> lib foo
>> :
>> funky.cpp
>> :
>> <define>COOL=1
>> <*><define>ENABLE_LOG=1
>> <threading>multi:<*><define>THREAD_SAFE=1
>> <link>shared:<define>BUILD_DLL=1
>> :
>> debug
>> :
>> <link>shared:<define>USE_DLL=1
>> ;
>>
>>
>> Thoughts?
I should mention that there is already a way to reduce the duplication
at the cost of a bit more typing. What I do in a few really long
requirements, I have one library that has about 15 of defines, is to use
an alias to hold the common parts...
alias ~foo : : : :
<define>ENABLE_LOG=1
<threading>multi:<define>THREAD_SAFE=1
;
lib foo
:
~foo
funky.cpp
:
<define>COOL=1
<link>shared:<define>BUILD_DLL=1
:
debug
:
<link>shared:<define>USE_DLL=1
;
But that is not ideal as it separates the requirements from the point
they are relating to. And from someone else reading it, it may not be
obvious what's going on.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
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