The example in contrib works, as does the one in biconcor.
The examples in lm and moses don't work at the moment,
but checking them in anyway as a starting point
for any potential work on them next week during the
MT Marathon.
If libmoses.a was compiled with LM_IRST,
then the following flags must be passed to the linker
when compiling CreateOnDiskPt:
-L $(XCODE_MOSES_LIBRARY_IRSTLM)
-lirstlm
If libmoses.a was compiled with LM_SRI,
then the following flags must be passed to the linker
when compiling CreateOnDiskPt:
-L $(XCODE_MOSES_LIBRARY_SRILM)
-ldstruct
-liconv
-lz
-lmisc
-loolm
Additionally, if libmoses.a was compiled with LM_SRI,
and SRILM was compiled with lbfgs,
then the following flags must be passed to the linker
when compiling CreateOnDiskPt:
-L $(XCODE_MOSES_LIBRARY_LBFGS)
-Xlinker -search_paths_first
-llbfgs
An note of explanation here may be warranted
with regard to the above lbfgs-related flags:
Mac OS X ships with a dynamic library that is loaded
with the flag -lz. SRILM compiles its own version of this
library. If SRILM is compiled statically, this becomes a problem.
We need XCode to link against the SRILM version of zlib,
but by default, the linker will search through all known library paths
for a dynamic version first. Only if no dynamic version is found will
it then search the library paths for a static version.
The fix for this problem is to use the -Xlinker flag to pass an additional
flag to the linker: -search_paths_first. This flag forces to linker to
iterate only once through each directory in its library path; within each
such directory it will first look for a dynamic version and
then, if necessary, for a static version. This solves the problem.
Have working targets for kenlm binaries
and for libmoses, with the caveat that
only source files from the lm, moses, and util dirs
are currently included in libmoses.
The next step is adding the other relevant dirs
to libmoses.
Project is now configured such that it should compile
cleanly with or without optional libraries.
To compile the project, the user must (at minimum) have boost installed.
If boost is installed in a standard location, such as /usr/local,
then XCode should be able to find boost without any help from the user.
If boost is in a non-standard location, the user must configure XCode
such that the Source Tree variable XCODE_MOSES_INCLUDE_BOOST is set to
the directory where boost is installed.
For example, if you download and unzip boost in /path/to/boost_1_53_0,
then after compiling boost, headers would be located in
/path/to/boost_1_53_0/include and libraries would be located in
/path/too/boost_1_53_0/lib. In this case, set XCODE_MOSES_INCLUDE_BOOST=
/path/to/boost_1_53_0/include.
If you want to compile using IRSTLM, RandLM, SRILM, or the HHMM SynLM,
you will need to set the paths to those projects' respective include dirs
in the respective corresponding Source Tree variables:
For IRSTLM:
XCODE_MOSES_INCLUDE_IRSTLM
For RandLM:
XCODE_MOSES_INCLUDE_RANDLM
For SRILM:
XCODE_MOSES_INCLUDE_SRILM
For the HHMM syntactic LM:
XCODE_MOSES_INCLUDE_SYNLM_RVTL
XCODE_MOSES_INCLUED_SYNLM_WSJPARSE
At the moment, the project is configured with the
LM_SRI, LM_IRST, and LM_RAND preprocessor macros enabled,
which means that to compile the project, the respective source tree
variables must be defined. Alternatively, you could remove those macros
from the project definitions.
