List Info

Thread: RFC: Repeated usage requirements.




RFC: Repeated usage requirements.
user name
2006-03-26 03:20:05
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... :|

--Emil
----- Original Message ----- 
From: "Rene Rivera" <grafik.listredshift-software.com>
To: "Boost.Build developer's and user's list"
<boost-buildlists.boost.org>
Sent: Saturday, March 25, 2006 12:44 PM
Subject: [Boost-build] [bbv2] RFC: Repeated usage
requirements.


> I'm porting over my build system from BBv1 to BBv2,
and to be nice, I'm
> trying to not hack things up too much. One of the
patterns I'm seeing is
> that in writing library targets I end up duplicating
many of the
> requirements into the usage-requirements.
>
> * That seems like a waste of typing resources 
>
> * It's prone to errors when I need to change one of
them and forget to
> change the other.
>
> 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?
>
>
> --
> -- 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
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
> 
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
RFC: Repeated usage requirements.
user name
2006-03-26 15: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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )