Specifying define on command line

We have a bug against C++ Boost where adding

	define=whatever

or

	cxxflags=whatever

on bjam command line has no effect. This is not specific
to C++ Boost. Given this Jamroot:

	exe a : a.cpp b ;
	lib b : b.cpp ;

and this command line:

	bjam -n define=FOO a

the 'a' target will be built with -DFOO and b will be built
without.

When I implemented that behaviour, I though it to be very
smart,
but now it seems confusing. Clearly users are accustomed to
define/cflags specification on the command line to apply
"globally".

I see two solutions:

	1. Make 'free' features like 'define' and 'cflags'
propagated. This
	will have undesirable effect that <define> set on
some target
	will propagate to all dependencies.
	2. Make free features specified on the command like apply
to
	all targets in the project located in ".", and
any child project.
	The only concern I have about this approach is that it
will
	still be impossible to specify define that will apply to
all
	compilations. That is, if I have two projects A and B,
	in different directories with separate Jamroots, where A
uses
	libraries from B, then:

		bjam define=FOO

	in A won't affect B.

Anybody can comment on those alternative or propose better
ones?

- Volodya




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

on Sun Aug 05 2007, Vladimir Prus <ghost-AT-cs.msu.su>
wrote:

> I see two solutions:
>
> 	1. Make 'free' features like 'define' and 'cflags'
propagated. This
> 	will have undesirable effect that <define> set
on some target
> 	will propagate to all dependencies.
> 	2. Make free features specified on the command like
apply to
> 	all targets in the project located in ".",
and any child project.
> 	The only concern I have about this approach is that it
will
> 	still be impossible to specify define that will apply
to all
> 	compilations. That is, if I have two projects A and
B,
> 	in different directories with separate Jamroots, where
A uses
> 	libraries from B, then:
>
> 		bjam define=FOO
>
> 	in A won't affect B.
>
> Anybody can comment on those alternative or propose
better ones?

3. Free features on the command line apply globally.

3 is the simplest way to address the problem, and probably
matches
most people's expectations.  I think 1 is the wrong way. 
The command
line options are an expedient and blunt instrument for
developers who
think they know what they're doing; I think they should be
treated
altogether differently from build properties specified in
Jamfiles,
which can be carefully tuned.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-cons
ulting.com

The Astoria Seminar ==> http://www.astoriasemin
ar.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

David Abrahams wrote:
> on Sun Aug 05 2007, Vladimir Prus
<ghost-AT-cs.msu.su> wrote:
>
>   
>> I see two solutions:
>>
>> 	1. Make 'free' features like 'define' and 'cflags'
propagated. This
>> 	will have undesirable effect that <define>
set on some target
>> 	will propagate to all dependencies.
>> 	2. Make free features specified on the command
like apply to
>> 	all targets in the project located in
".", and any child project.
>> 	The only concern I have about this approach is
that it will
>> 	still be impossible to specify define that will
apply to all
>> 	compilations. That is, if I have two projects A
and B,
>> 	in different directories with separate Jamroots,
where A uses
>> 	libraries from B, then:
>>
>> 		bjam define=FOO
>>
>> 	in A won't affect B.
>>
>> Anybody can comment on those alternative or propose
better ones?
>>     
>
> 3. Free features on the command line apply globally.
>
> 3 is the simplest way to address the problem, and
probably matches
> most people's expectations.  I think 1 is the wrong
way.  The command
> line options are an expedient and blunt instrument for
developers who
> think they know what they're doing; I think they should
be treated
> altogether differently from build properties specified
in Jamfiles,
> which can be carefully tuned.

I don't have a strong opinion on 2 vs. 3, but I agree that 1
is not a
good idea.  There are some libraries that need defines set
for building
which are unnecessary (and maybe even incorrect) for using
the library.

Phillip
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build