more bjam questions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

more bjam questions

Boost - Build mailing list
Here are two (more) questions about bjam internals:

1) what mechanism does bjam use to set up directories into which any
target files are being built ? Is there an implicit rule that is being
invoked for this to work automagically ?

2) Is there a mechanism to have bjam clean up intermediate files ? For
example, if I Use the `exe foo : foo.cpp ;` rule, there will be an
intermediate `foo.o` file generated. Can I instruct bjam to remove that
automatically in the process once `foo` is created ?

Thanks,

        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: more bjam questions

Boost - Build mailing list
AMDG

On 04/29/2017 07:38 AM, Stefan Seefeld via Boost-build wrote:
> Here are two (more) questions about bjam internals:
>
> 1) what mechanism does bjam use to set up directories into which any
> target files are being built ? Is there an implicit rule that is being
> invoked for this to work automagically ?
>

  It's implemented in common.MkDir here:
https://github.com/boostorg/build/blob/develop/src/tools/common.jam#L653
which is called by virtual-target.actualize-location
https://github.com/boostorg/build/blob/develop/src/build/virtual-target.jam#L606

> 2) Is there a mechanism to have bjam clean up intermediate files ? For
> example, if I Use the `exe foo : foo.cpp ;` rule, there will be an
> intermediate `foo.o` file generated. Can I instruct bjam to remove that
> automatically in the process once `foo` is created ?
>

  testing.jam does this.  The method is to mark the
intermediate files as TEMPORARY and then call
RmTemps $(target) : $(sources) ;
as the last updating action of the exe.
There is no high-level interface for this.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: more bjam questions

Boost - Build mailing list
On 29.04.2017 13:00, Steven Watanabe via Boost-build wrote:

> AMDG
>
> On 04/29/2017 07:38 AM, Stefan Seefeld via Boost-build wrote:
>> Here are two (more) questions about bjam internals:
>>
>> 1) what mechanism does bjam use to set up directories into which any
>> target files are being built ? Is there an implicit rule that is being
>> invoked for this to work automagically ?
>>
>   It's implemented in common.MkDir here:
> https://github.com/boostorg/build/blob/develop/src/tools/common.jam#L653
> which is called by virtual-target.actualize-location
> https://github.com/boostorg/build/blob/develop/src/build/virtual-target.jam#L606
>
>> 2) Is there a mechanism to have bjam clean up intermediate files ? For
>> example, if I Use the `exe foo : foo.cpp ;` rule, there will be an
>> intermediate `foo.o` file generated. Can I instruct bjam to remove that
>> automatically in the process once `foo` is created ?
>>
>   testing.jam does this.  The method is to mark the
> intermediate files as TEMPORARY and then call
> RmTemps $(target) : $(sources) ;
> as the last updating action of the exe.
> There is no high-level interface for this.

Wonderful, thanks for the prompt reply !

        Stefan


>
> In Christ,
> Steven Watanabe
>
> _______________________________________________
> Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build


--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: more bjam questions

Boost - Build mailing list
In reply to this post by Boost - Build mailing list
Hi Steven,

here is a late follow-up question:

On 29.04.2017 13:00, Steven Watanabe via Boost-build wrote:

>> 2) Is there a mechanism to have bjam clean up intermediate files ? For
>> example, if I Use the `exe foo : foo.cpp ;` rule, there will be an
>> intermediate `foo.o` file generated. Can I instruct bjam to remove that
>> automatically in the process once `foo` is created ?
>>
>   testing.jam does this.  The method is to mark the
> intermediate files as TEMPORARY and then call
> RmTemps $(target) : $(sources) ;
> as the last updating action of the exe.
> There is no high-level interface for this.

It seems bjam internally doesn't recognize intermediate files. I.e., if
I have a dependency graph such as foo -> foo.o -> foo.cpp, then remove
the intermediate foo.o at the end, bjam would in a subsequent invocation
rebuild foo.o and foo, rather than recognizing that foo is up-to-date as
it is newer than foo.cpp, even though the intermediate foo.o does no
longer exist.
Is that not the normal / expected semantic of an intermediate file in
bjam ? Or am I missing something ?

Thanks,
        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: more bjam questions

Boost - Build mailing list
AMDG

On 06/08/2017 01:18 PM, Stefan Seefeld via Boost-build wrote:

> here is a late follow-up question:
>
> On 29.04.2017 13:00, Steven Watanabe via Boost-build wrote:
>>   testing.jam does this.  The method is to mark the
>> intermediate files as TEMPORARY and then call
>> RmTemps $(target) : $(sources) ;
>> as the last updating action of the exe.
>> There is no high-level interface for this.
>
> It seems bjam internally doesn't recognize intermediate files. I.e., if
> I have a dependency graph such as foo -> foo.o -> foo.cpp, then remove
> the intermediate foo.o at the end, bjam would in a subsequent invocation
> rebuild foo.o and foo, rather than recognizing that foo is up-to-date as
> it is newer than foo.cpp, even though the intermediate foo.o does no
> longer exist.
> Is that not the normal / expected semantic of an intermediate file in
> bjam ? Or am I missing something ?
>

That's exactly what TEMPORARY is supposed to handle.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: more bjam questions

Boost - Build mailing list
On 08.06.2017 15:48, Steven Watanabe via Boost-build wrote:

> AMDG
>
> On 06/08/2017 01:18 PM, Stefan Seefeld via Boost-build wrote:
>> here is a late follow-up question:
>>
>> On 29.04.2017 13:00, Steven Watanabe via Boost-build wrote:
>>>   testing.jam does this.  The method is to mark the
>>> intermediate files as TEMPORARY and then call
>>> RmTemps $(target) : $(sources) ;
>>> as the last updating action of the exe.
>>> There is no high-level interface for this.
>> It seems bjam internally doesn't recognize intermediate files. I.e., if
>> I have a dependency graph such as foo -> foo.o -> foo.cpp, then remove
>> the intermediate foo.o at the end, bjam would in a subsequent invocation
>> rebuild foo.o and foo, rather than recognizing that foo is up-to-date as
>> it is newer than foo.cpp, even though the intermediate foo.o does no
>> longer exist.
>> Is that not the normal / expected semantic of an intermediate file in
>> bjam ? Or am I missing something ?
>>
> That's exactly what TEMPORARY is supposed to handle.

Thanks for confirming that. It turns out I had not set the target's
flags properly. Doing that reveals an issue, though:
In a test case I have a dependency chain of NOTFILE targets, and even
though I request them to be updated (and they are reported to be
updated), no action / command is executed to update them. Debugging this
reveals their "fate" variable is set to "STABLE". Any idea why that
would happen ? What do I need to do to tell bjam a NOTFILE target needs
to be updated ?

Thanks again,
        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: more bjam questions

Boost - Build mailing list
AMDG

On 06/08/2017 04:07 PM, Stefan Seefeld via Boost-build wrote:

>
> Thanks for confirming that. It turns out I had not set the target's
> flags properly. Doing that reveals an issue, though:
> In a test case I have a dependency chain of NOTFILE targets, and even
> though I request them to be updated (and they are reported to be
> updated), no action / command is executed to update them. Debugging this
> reveals their "fate" variable is set to "STABLE". Any idea why that
> would happen ? What do I need to do to tell bjam a NOTFILE target needs
> to be updated ?
>

  NOTFILE targets typically need ALWAYS if they
have no dependencies.  If they have dependencies,
then they will be updated only when the dependencies
are outdated.

In Christ,
Steven Watanabe

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