El dv 23 de 03 de 2012 a les 12:23 +0100, en/na Kevin Brubeck Unhammer
va escriure:
> 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?
It sounds ok, gives more functionality without breaking how things are.
+1
Fran
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
