Re: [Boost-build] Problem with notfile target

Subject: Re: [Boost-build] Problem with notfile target
From: Ian Emmons (iemmons_at_[hidden])
Date: 2008-11-30 16:12:50

Volodya,

Again, thanks for your help.

On Nov 29, 2008, at 1:57 PM, Vladimir Prus wrote:

> On Saturday 29 November 2008 21:05:45 Steven Watanabe wrote:
>> AMDG
>>
>> Ian Emmons wrote:
>>>> Probably, instead of adding the target to sources, you can use
>>>>
>>>>    <dependency>JniHeaders
>>>>
>>>> in requirements?
>>>>
>>>> - Volodya
>>>
>>> Thanks for the quick reply.
>>>
>>> Your suggestion does indeed cause the JniHeaders target to run  
>>> before
>>> the library is built, but it has two undesirable side effects:
>>>
>>> * It causes the library is completely rebuilt every time, as if I  
>>> did
>>> a bjam --clean beforehand.
>>
>> notfile targets are always built.  You can try something like:
>>
>> make JniHeaders.txt : : @BuildJniHeaders ;
>> alias JniHeaders : JniHeaders.txt ;
>> actions BuildJniHeaders
>> {
>>    ant jniHeaders
>>    echo Updated >$(<)
>> }
>>
>> so that bjam has something to check the timestamp of.
>
> But on the other hand, while always running 'ant' might be  
> reasonable, I
> am not sure that causing dependents of notfile to be always rebuilt  
> makes
> sense.
>
> I guess I can make it not happen -- does that seem right?
>
> - Volodya

In this particular case, my ant script does dependency checking of its  
own, so it doesn't regenerate the JNI headers unless one of the Java  
sources has changed.  Thus, even though ant runs every time, the ideal  
behavior would be that dependents of this notfile target would be  
unaffected by the fact that it ran.  But I'm sure that someone else  
has another case where the fact that the notfile target always runs  
means that some dependency is always getting updated, and therefore  
the current behavior is desired.

I guess the ideal would be two kinds of notfile targets, one that  
behaves as-is, and another (notfile-no-force, perhaps?) which never  
forces dependent targets to be rebuilt.  Then the writer of the  
notfile target can choose the correct one.

Another resolution to my particular problem is to realize that I'm an  
old hand at ant scripts and a newbie to boost.build (which is pretty  
darn slick, BTW).  So in my haste to get my build working, I'm trying  
to do the Java part with the most familiar tool, when it might be  
better for me to figure out the make and generate rules so I can do  
the whole thing in the jam file.

Ultimately, as I mentioned in my reply to Steven, it would be great if  
boost.build could have out-of-the-box support for Java builds and JNI  
headers.

Thanks again,

Ian