Hi,
If you edited a C++ or header file, bjam should notice that.
If the files haven't changed but you're using #ifdef to change how they
are compiled, then it's best to add the specific .o files to the list of
targets under always-if-changed. List the low-level targets, not the
high-level ones. Currently, you have moses and moses_internal listed,
which will cause it to relink but not build the underlying files.
And keep in that once you get this working, delete the bin directories
because some cruft slipped past when it wasn't working.
You'll also always be safe if you consistently pass the same command
line arguments to bjam. ./previous.sh helps with this.
Kenneth
On 07/02/2012 04:39 PM, Ales Tamchyna wrote:
> Thanks for the quick reply! I edited the Jamfile to work similarly. From
> what I understand, this helps in the situation when I compile with VW
> and then decide to compile without it (or vice versa).
>
> The main problem is still there though -- even though I don't change the
> compilation flags and actually make a change in the source files, it is
> sometimes ignored by bjam. But I think I made some mistake in the
> Jamfile and it interacts badly with my #ifdef statements (maybe it isn't
> passed to all the relevant files). Anyway, thanks for the help, I'll try
> to figure it out; in the meantime, we can use the version with these
> statements commented out.
>
> Best,
> Ales
>
> Dne 2.7.2012 13:05, Kenneth Heafield napsal(a):
>> Hi,
>>
>> This is a long-standing bug in bjam and many build systems. The issue
>> is that it analyzes the current build graph, checks that timestamps are
>> consistent with that graph, and assumes the files match the current
>> build if so. If you had a Makefile, ran make, edited the Makefile to
>> change commands, and ran make again, it would think the build is complete.
>>
>> It started causing trouble when people built with one set of language
>> models then built with another, so I put a kludge in that saves the
>> relevant command line options to a file and forces a rebuild.
>>
>> In response to your mail, I factored the kludge into a function.
>> Please git pull then look at the tail end of moses/src/LM/Jamfile:
>>
>> path-constant LM-LOG : bin/lm.log ;
>>
>> local current = ;
>> for local i in srilm irstlm randlm {
>> local optval = [ option.get "with-$(i)" ] ;
>> if $(optval) {
>> current += "--with-$(i)=$(optval)" ;
>> }
>> }
>>
>> current = $(current:J=" ") ;
>> current ?= "" ;
>>
>> always-if-changed $(LM-LOG) $(current) : Factory.o LM ;
>>
>> You can also look at the end of jam-files/sanity.jam .
>>
>> Kenneth
>>
>> On 07/02/2012 11:33 AM, Ales Tamchyna wrote:
>>> Hi,
>>>
>>> we are implementing phrase sense disambiguation in Moses, which requires
>>> linking it with Vowpal Wabbit. We have been struggling with bjam,
>>> encountering a bunch of random errors and unexpected behavior:
>>>
>>> * bjam seems to ignore changes sometimes, it only says "found X
>>> targets...", but doesn't update (yet the moses binary timestamp changes
>>> -- it doesn't include the new modifications though).
>>>
>>> * It seems that the final build is sometimes erroneous, resulting in
>>> random crashes in places that have nothing to do with the code changes I
>>> made (removing all 'bin' directories and doing bjam -a seems to help).
>>>
>>> * It looks like I was able to get rid of these errors by removing all
>>> occurrences of #ifdef HAVE_VW and #endif from my code (but now normal
>>> users can't build this branch).
>>>
>>> I'm wondering if a bjam expert (Ken? :) could take a look at the
>>> attached Jamfile and let me know if I did something wrong. My code is in
>>> the damt_phrase branch.
>>>
>>> Thanks!
>>>
>>> Ales Tamchyna
>>>
>>>
>>> _______________________________________________
>>> Moses-support mailing list
>>> [email protected]
>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>> _______________________________________________
>> Moses-support mailing list
>> [email protected]
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>
> _______________________________________________
> Moses-support mailing list
> [email protected]
> http://mailman.mit.edu/mailman/listinfo/moses-support
_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support
