portability testing (was: How to handle data/script files in a VPATH build ?)

[Ralf Wildenhues]

* Steffen Dettmer wrote on Fri, Feb 12, 2010 at 02:15:04PM CET:
> Just because of my curiosity, when writing portable packages
> (i.e. packages compiling ON many platforms), on which platform
> this is recommended to do so?

I'd recommend testing on as many as you can get hold on, and as
old and new systems as you still aim to support, and with as many
and as diverse compilers and toolchains as you can afford.

FWIW, I do most autotools development on GNU/Linux and then test
specific code pieces on known-problematic systems; the Autoconf
and Gnulib manuals can provide good hints here.  Before a release,
I try to regression-test everywhere.

A corollary of this is that your package should easily be testable
and testing should expose as many features as possible.

> >>                   | sort    >> ${_mak}
> >
> > With sort, you should always normalize the locale, i.e.,
> >  LC_ALL=C sort
> 
> Is having `LC_COLLATE="POSIX"' also sufficient and correct?

Well, if one of your users overrides LC_COLLATE with LC_ALL, then it
may not be sufficient.

> (we have this in /etc/profile). But I added export LC_ALL=C to all
> that scripts to go sure :)

> > Well, don't look at the GNU find(1) manpage if you're looking for
> > portable options only.  That's what POSIX/SUSv3 is for; the findutils
> > info pages are more verbose about portability, too.
> 
> How do I get the findutils info pages? Is this `info find' or is
> there another one?

On my system `info find' is sufficient.  You might need `info findutils'
instead, I guess, if the former brings up the man page.

Cheers,
Ralf