[XeTeX] Patches for XeTeX installation scripts (XeTeX on FreeBSD + more)

[Jonathan Kew]

On 9 Jul 2007, at 4:13 am, Nikola Lecic wrote:
>
> I'm not aware of a real one-command equivalent, outside of Mac of
> course... (realpath(1) is just a ~25 lines implementation of
> realpath(3), which is itself present on Mac OS X, right?). Anyway,
> 'cd -P' should work, i.e. something like
>
>   #!/bin/sh
>   real_path()
>   {
>           current_path=`pwd` && relative_path=$1
>
>           cd -P ${relative_path}   # resolving symlinks and './..'s
>
>           real_path=`pwd` && cd ${current_path}
>           echo ${real_path}
>   }
>
> should return the absolute path.

OK, thanks.

> I'd like the installation process to honour symlinks since I wouldn't
> like hardcoding of the path I temporarily use (passed to  
> 'configure' by
> kpsewhich).
>
> Actually, what would you do in this (imaginable) situation? Here are
> some questions I included in the diff, could you please clarify these
> things:
>
> (1) Does XeTeX hardcode TeX system elements paths provided/determined
>     during installation process? I'd say that it doesn't do so because
>     it works normally if I change the object of texlive symlink -- but
>     it's better to ask.

I believe you're right, in general. All this stuff should work the  
same in xetex as in other kpse-based *tex binaries. I believe the  
build-time paths are compiled in, but will only be used as a last  
resort if no texmf.cnf is found via the usual kpathsearch process,  
based on the actual location of the binary. So it doesn't normally  
matter what the compile-time paths are, though it would seem tidier  
if they match a typical installation rather than some arbitrary build  
setup.

> (2) Does texhash's behaviour differ depending on whether the path it
>     uses respects symlinks?
>
> (3) Most importantly, can kpsewhich honour symlinks?

I don't know.

(Sorry, this is an area that I really don't know much about. I just  
follow what the rest of the teTeX/texlive world seems to be doing.)

>
> If XeTeX doesn't hardcode TeX paths and relies on kpsewhich  
> everywhere,
> then maybe this whole thing is not needed.

It should rely on kpse functions, so I don't think the hardcoded  
paths really matter; but I do like the idea of making them more  
consistent and portable, to the extent that we can.

I've been experimenting with your patches, and made just a few small  
changes based on what I've seen on OS X and Linux. I've now checked- 
in updated versions of the scripts, and hope these will work for you.  
(It seemed easier to go ahead and check these into SVN rather than  
swap patches back and forth.)

Please let me know if I've broken anything in the changes I've made,  
and I'll be happy to make further adjustments.

Many thanks,

JK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tug.org/pipermail/xetex/attachments/20070710/ec5b9e4e/attachment.html