commandline

Hi All,

I have a small question regarding <define>

If I specify a define on the commandline, like
   
    bjam toolset=gcc define=BLA

I get a

    'error: Duplicate name of actual target'

on the lib(s) in the jamfile.

Bu when I specify the (exe) target, like

    bjam my-exe toolset=gcc define=BLA

there is no problem ...

What happens here? I would like to use defines on the
commandline, 
because having them inside the jamfile will create a very
complex jamfile.

(I use:
bjam --version
Boost.Build V2 (Milestone 11)
Boost.Jam 03.1.14

Help would be very much appriciated!

Regards, Dirk

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

Dirk Griffioen wrote:

> Hi All,
> 
> I have a small question regarding <define>
> 
> If I specify a define on the commandline, like
>    
>     bjam toolset=gcc define=BLA
> 
> I get a
> 
>     'error: Duplicate name of actual target'
> 
> on the lib(s) in the jamfile.

You bug report does not include neither a minimal
project reproducing this behaviour, not the error message,
so strictly speaking I cannot reproduce this. Please
include
that information for any subsequent bug reports.

This time, I happen to know what's wrong. Say you have:

        exe a : a.cpp helper ;
        lib helper : helper.cpp ;

And say

        bjam toolset=gcc define=BLA

Boost.Build first builds 'helper' with define=BLA.
Then it builds a with define=BLA. That requires also
building
helper. Since 'define' is not a propagated feature, this
requests a build of 'helper' without define. Now, we've
built
'helper' twice, and build requests differed only in
'define'. Since
define is not represented in target path, there's no way we
can
assign target paths to build versions of 'helper' and we
error out.

> Bu when I specify the (exe) target, like
> 
>     bjam my-exe toolset=gcc define=BLA
> 
> there is no problem ...
> 
> What happens here? I would like to use defines on the
commandline,
> because having them inside the jamfile will create a
very complex jamfile.
> 
> (I use:
> bjam --version
> Boost.Build V2 (Milestone 11)

Please use the nightly build from boost.org/boost-build2;
there, 'define'
specified on command line applies to all attempts to build
any targets.

- Volodya


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

Hi Vladimir,

Vladimir Prus wrote:
> You bug report does not include neither a minimal
> project reproducing this behaviour, not the error
message,
> so strictly speaking I cannot reproduce this. Please
include
> that information for any subsequent bug reports.
>
>   
I will & sorry I didn't ...
> This time, I happen to know what's wrong. Say you
have:
>
>         exe a : a.cpp helper ;
>         lib helper : helper.cpp ;
>
> And say
>
>         bjam toolset=gcc define=BLA
>
> Boost.Build first builds 'helper' with define=BLA.
> Then it builds a with define=BLA. That requires also
building
> helper. Since 'define' is not a propagated feature,
this
> requests a build of 'helper' without define. Now, we've
built
> 'helper' twice, and build requests differed only in
'define'. Since
> define is not represented in target path, there's no
way we can
> assign target paths to build versions of 'helper' and
we error out.
>
>   
Thanks for the explanation!
>
> Please use the nightly build from
boost.org/boost-build2; there, 'define'
> specified on command line applies to all attempts to
build any targets.
>
>   
That might be a bit more than I bargained for, I took the
zip from the 
boost build v2 page and built the exe, it works fine without
the define 
on the commandline, but with it:
- bjam.exe starts using up to 500MB of memory (which is
dropped eventually)
- it takes a really long time (>5 minutes or more)

I do have boost as part of the project, so having the define
on all 
targets might be a bit much, I was more looking for just my
own targets 
to have the flag ...

Thanks anyway!
> - Volodya
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
>
>   

-- 
CodeShop BV
Wenckebachweg 150-B
1096 AB Amsterdam

www.code-shop.com
+31 6 411 92 024

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

Dirk Griffioen wrote:

> Hi Vladimir,
> 
> Vladimir Prus wrote:
>> You bug report does not include neither a minimal
>> project reproducing this behaviour, not the error
message,
>> so strictly speaking I cannot reproduce this.
Please include
>> that information for any subsequent bug reports.
>>
>>   
> I will & sorry I didn't ...
>> This time, I happen to know what's wrong. Say you
have:
>>
>>         exe a : a.cpp helper ;
>>         lib helper : helper.cpp ;
>>
>> And say
>>
>>         bjam toolset=gcc define=BLA
>>
>> Boost.Build first builds 'helper' with define=BLA.
>> Then it builds a with define=BLA. That requires
also building
>> helper. Since 'define' is not a propagated feature,
this
>> requests a build of 'helper' without define. Now,
we've built
>> 'helper' twice, and build requests differed only in
'define'. Since
>> define is not represented in target path, there's
no way we can
>> assign target paths to build versions of 'helper'
and we error out.
>>
>>   
> Thanks for the explanation!
>>
>> Please use the nightly build from
boost.org/boost-build2; there, 'define'
>> specified on command line applies to all attempts
to build any targets.
>>
>>   
> That might be a bit more than I bargained for, I took
the zip from the
> boost build v2 page and built the exe, it works fine
without the define
> on the commandline, but with it:
> - bjam.exe starts using up to 500MB of memory (which is
dropped
> eventually) - it takes a really long time (>5
minutes or more)

Are you saying this is new performance regression, and that
M11 
acts better, on same project (when you don't specify define
on command
line).

- Volodya


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