Currently, a modes file looks like this:

  /usr/local/bin/lt-proc -w
  /usr/local/bin/nb-nn.automorf-no-cp.bin|/usr/local/bin/cg-proc -w
  /usr/local/bin/nb-nn.rlx.bin|/usr/local/bin/apertium-tagger -g $2
  /usr/local/bin/nb-nn.prob | # etc

with full paths to each program. This works fine in many cases, but as
Jacob Nordfalk noted, it gets in the way if you want to e.g. replace
programs with their Java counterparts, but still use the installed .mode
files (not every pair installs modes.xml, so that's not reliable).

Other users have wanted to keep HFST or vislcg3 in one prefix, and
apertium/lttoolbox in another, for whatever reason. One could also
imagine user who installs apertium + lttoolbox with their package
manager (which puts things /usr), but finds no recent enough package for
vislcg3, and installs that from source with the default options (ie. to
/usr/local). The user tries the standard Unix way of putting the path to
cg-proc in $PATH, but since modes files have the path to a non-existant
program hard-coded, the user has the choice between either installing
apertium/lttoolbox from svn, or messing up /usr with packages that
really belong in /usr/local.

This could be more unixy by simply using $PATH instead. Here's a
proposal:

1) When generating modes files, if the prefix attribute is not set,
   don't set a prefix at all, but assume the program is in path:

$ svn diff apertium/modes2bash.xsl 
Index: apertium/modes2bash.xsl
===================================================================
--- apertium/modes2bash.xsl     (revision 36540)
+++ apertium/modes2bash.xsl     (working copy)
@@ -48,12 +48,9 @@
   <xsl:choose>
     <xsl:when test="@prefix">
       <xsl:value-of select="@prefix"/>
+      <xsl:value-of select="string('/')"/>
     </xsl:when>
-    <xsl:otherwise>
-      <xsl:value-of select="$prefix"/>
-    </xsl:otherwise>
   </xsl:choose>
-  <xsl:value-of select="string('/')"/>
   <xsl:value-of select="./@name"/>
   <xsl:for-each select="./*">  
     <xsl:value-of select="string(' ')"/>


2) We probably want the user (or some third-party program) to be able to
   call /apertium-prefix/bin/apertium even if /apertium-prefix/bin is
   not in PATH, so ensure PATH contains at least /apertium-prefix/bin/
   before running the modes file when starting the apertium script:

$ svn diff apertium/apertium-header.sh 
Index: apertium/apertium-header.sh
===================================================================
--- apertium/apertium-header.sh (revision 36540)
+++ apertium/apertium-header.sh (working copy)
@@ -1,3 +1,4 @@
+PATH="${APERTIUM_PATH}:${PATH}"
 PAIR=""
 INPUT_FILE="/dev/stdin"
 OUTPUT_FILE="/dev/stdout"


The change to apertium/apertium-header.sh is backwards compatible with
old modes files, so no need to recompile all pairs. I don't see how this
could break anything, but it could mean less trouble for new developers
who have programs installed to different prefixes and expect that
setting $PATH should solve their problems. And anyone wanting a Java
version of the apertium script can use modes files as they are by
setting some other $PATH.

(Note: since the apertium script prepends to PATH, it will prefer files
in APERTIUM_PATH, so you can't put an experimental lt-proc in
$HOME/foo/bin/lt-proc and do "PATH=$HOME/foo/bin /usr/bin/apertium". But
you can't do that now either, and if you've installed lt-proc to a
prefix you're surely able to install apertium to the same prefix.
Putting APERTIUM_PATH in PATH in the apertium script is necessary if you
want it to be runnable by other programs that don't have PATH set at
all, so I think that line should be there.)



So what do people think?


-Kevin


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff

Reply via email to