Hi,

        Sorry for the lack of documentation.  I've added comments to 
moses/src/LM/Jamfile which is admittedly gory due to the many 
command-line options it handles.  If your code is independent of the LM 
toolkit, you can add it to this rule:

lib LM : Base.cpp Factory.o Implementation.cpp Joint.cpp Ken.cpp 
MultiFactor.cpp Remote.cpp SingleFactor.cpp ORLM.o ;

If your code depends on e.g. IRSTLM and needs access to IRSTLM headers, 
look at these rules:

   obj IRST.o : IRST.cpp ..//headers : <include>$(with-irstlm)/include 
<include>$(with-irstlm)/include/irstlm ;
   alias irst : IRST.o irstlm : : : <define>LM_IRST ;

You can copy the line for IRST.o (to, say, produce Foo.o) and add it to 
the dependencies of the irst alias:

   obj IRST.o : IRST.cpp ..//headers : <include>$(with-irstlm)/include 
<include>$(with-irstlm)/include/irstlm ;
   obj Foo.o : Foo.cpp ..//headers : <include>$(with-irstlm)/include 
<include>$(with-irstlm)/include/irstlm ;
   alias irst : IRST.o Foo.o irstlm : : : <define>LM_IRST ;

If copying gets overbearing, it's possible to collapse these.

On a related note, I'd like to lobby for IRSTLM to include a version 
number in some header file so that the build system can test for the 
correct version rather than always print a warning.

Kenneth

On 03/20/2012 09:47 AM, Nick Ruiz wrote:
> Thanks, Kenneth. You were right, I was using the src/LM directory, since
> my feature is language model-related, so I had thought it would be
> logical place for the source. Unfortunately, the src/LM directory isn't
> swept in the same way as the src directory, according to the Jamfiles.
> So, rather than coupling my feature with the code in the LM dir, I
> simply moved my sources up to the parent directory and everything
> compiles smoothly.
>
> Nick
>
> On 03/19/2012 10:13 PM, Kenneth Heafield wrote:
>> Hi,
>>
>>      The equivalent is Jamfile.  Take a look at mert/Jamfile; the basics are
>> fairly easy.  Some Jamfiles use a glob e.g. moses/src/Jamfile:
>>
>> lib moses :
>> #All cpp files except those listed
>> [ glob *.cpp DynSAInclude/*.cpp : ThreadPool.cpp
>> SyntacticLanguageModel.cpp ]
>> synlm ThreadPool CYKPlusParser//CYKPlusParser LM//LM
>> RuleTable//RuleTable Scope3Parser//Scope3Parser headers ../..//z
>> ../../OnDiskPt//OnDiskPt ;
>>
>>      Since it seems you made a new directory, you can either add to the glob
>> like DynSAInclude/*.cpp or create a Jamfile for your directory and
>> reference it as a library like CYKPlusParser does.
>>
>> Kenneth
>>
>> On 03/19/2012 04:42 PM, Nick Ruiz wrote:
>>> Hi everyone,
>>>
>>> I have a question about adding new feature functions using bjam. I
>>> created a new .h and .cpp file and incorporated the feature in
>>> StaticData.h/.cpp; however, running bjam causes the friendly "undefined
>>> reference" error when I try to call my new feature's constructor. The
>>> problem is that the feature's source files aren't included in the build
>>> process.
>>>
>>> How do I add the new files in the build process with Boost? I assumed
>>> that the subdirectories would automatically be scanned, since I didn't
>>> immediately see something like a Makefile to work from. Or maybe I just
>>> missed it. :)
>>>
>>> Thanks,
>>> Nick
>>> _______________________________________________
>>> 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

Reply via email to