[tlbuild] Gregorio test failures

[Henry So Jr.]

The issue on our tracker is

    https://github.com/gregorio-project/gregorio/issues/806

On Saturday, 23 January 2016 at 12:28:44 am +0000, Karl Berry wrote:
> I'd have to expose a well-named function to do it, since those are
> static functions right now.  Before I do that, would you mind seeing if
> it actually does the job in your case?  E.g., devise a new function
> kpse_canonicalize to wrap those two function in whatever way is needed,
> and we can go from there?

At this point, I don't think this is necessary any more, but we'll see
as we try to build this on more architectures.

> Alternatively, I wonder if it's really needed to canonicalize the
> path anyway.  What are you gaining?  To look for a file relative to
> argv[0], maybe you could just do string operations to create the name to
> look for.  If you see what I mean.  It's easier for users if the paths
> used are relative to the paths they actually see/use, before symlink
> expansion and all.

The reason we are doing this is to check that the input file is not the
same as the output file to prevent accidentally clobbering a source
file, which was unfortunately and uncommonly easy to do (user error,
yes, but it was still easy to do).  We have taken three measures
(including this one) to reduce the problem.

> Alternatively 2, in this particular case, I think it would be the lesser
> evil to call realpath() with a fixed array.  The gnulib replacement, as
> pointed out, has far too many dependencies to be realistically usable in
> our context.  Sad but true.  For bonus points, sure, could autoconfigure
> whether NULL as the second argument work (maybe such a macro has already
> been written in autoconf-archive, or somewhere), but personally, I
> probably wouldn't bother :).

This is what I have done to get things working for Mojca.  I copied in
the gnulib autoconf macros (but not gnulib itself) that check for a
working realpath, and if that check fails (which it does for Solaris), I
pass a buffer malloc'd to PATH_MAX size.

> Maybe open an issue for this on your tracker and we can discuss there,
> since all the TL builders don't need to be in on all these gory details.

Since I was replying anyway to give you the issue URL, I figured I might
as well answer your points.

Henry