Hi James,
* James Laird wrote on Mon, Oct 10, 2005 at 08:11:31PM CEST:
>
> My package (hdf.ncsa.uiuc.edu/HDF5) has historically tested that the tr
> utility works correctly at configure time. Apparently there are two
> kinds of tr which expect slightly different syntax for their input.
What are the exact differences? What does "the other tr" do in the test
you quoted?
> We have now encountered a platform where setting the path to point to the
> "correct" tr confuses the path to some libraries that the compiler needs.
Let me guess: some w32 platform?
In general, two differences between execution from within `configure'
and outside are likely candidates for different behavior: setting of
PATH, and locale settings. Just FYI.
> What we'd like to do is to set an environment variable for tr rather than
> changing the global path. We can change our own configure tests, but it
> looks like aclocal.m4 uses tr by name.
Try using AC_PATH_PROG instead of AC_CHECK_PROG. The program `aclocal'
has little business with tests that end up inside the file `aclocal.m4':
it merely collects all needed macros into that file.
> If aclocal is happy with either version of tr, so much the better. If
> not, I'd like to suggest that it replace "tr" with the environment
> variable "$TR" and add a test in configure to ensure that the correct
> version of tr is being used.
Can't see where aclocal makes special use of "tr", see above.
I hope this random collection of comments helps you a bit. If not,
please be more specific in what does not work for you (including error
output, used tools with versions, and, if possible, a small example to
reproduce the problem). I have not understood what the problem is you
are describing.
Cheers,
Ralf
> Such a test might look like this:
>
> AC_MSG_CHECKING([if tr works])
> if test "X${TR}" = "X"; then
> TR=tr
> fi
> TR_TEST="`echo Test | ${TR} 'a-z,' 'A-Z '`"
> if test "${TR_TEST}" != "TEST"; then
> AC_MSG_ERROR([tr program doesn't work])
> else
> AC_MSG_RESULT([yes])
> fi
