Autoconf Digest, Vol 128, Issue 6

[David A. Wheeler]

The POSIX-style shell tosses the double quotes at first point of use.

When a variable reference is itself "..." quoted, like "$variable",
a POSIX shell does NOT toss the double-quotes.
When it's unquoted, a POSIX shell *does* toss the double-quotes.
I am *counting* on that behavior to make this scheme work.

This works out in makefiles at least.
Going back to my examples in a makefile:
SBCL =/cygdrive/c/"Program Files/Steel Bank Common Lisp/1.2.6/sbcl"
EGREP = /usr/bin/grep -E

Typically programs are invoked in a makefile as $(NAME),
and this 'just works' in the proposed convention:
dostuff:
$(SBCL) < x.src > x.dest
$(EGREP) pattern y.src >> x.dest

Arguments must be escaped varying amounts of times to survive a given
data path, and the data path may not be a fixed one.

Many shell programmers, out of habit,
always reference shell variables as "$variable_name" instead of $variable_name,
and then quoting survives just fine. It might not be hard to fix up the
remaining ones (it is a good habit anyway).

There might need to be a way to vary how replacements are done
(e.g., a Makefile would have the quoting scheme, while a #include file would not).
But the fundamental problem is that there's no way to distinguish the
different uses of spaces; once there's an input and storage convention,
you can then decide how to best output them.

--- David A. Wheeler

[Fotis Georgatos]

Hello * and a happy new year,

As regards $subject, this so-called STRING_ENCODING_CHARMAP may be relevant:
https://github.com/hpcugent/easybuild-framework/blob/master/easybuild/tools/filetools.py#L59
Look around line L1000 for the rational of that design and some pointers.

Basically, ` ` becomes `_space_` and so on, for many more potentially tricky characters.
The aim was to have freedom in relation to packages/filenames. It seems to work OK! (*)

I propose developing and documenting a standard convention for spaces in pathnames that
focuses on making things easier for *users* - the builders of the software.
This convention could be enabled by some statement in autoconf.ac, and perhaps
it could be enabled by default some time in the future.
If autoconf defined a simple convention for differentiating spaces in pathnames
from spaces in argument separators, it might "just work". It'd be tricky to find such a convention,
but if one can be found, autoconf would be able to adapt to many common systems.

(*)

To make a long story short, we faced the same problem during EasyBuild
open source project, for building software intended for HPC platforms;
in fact, that one issue triggered me to request EB’s first hackathon whereby,
in the issued Pull Request, I contained the wishes of a handful of people.
It is not known if there are better ways to go about it - and if so, what’s that?

We opted for that solution as the least hackish or, least worst.
It does not preserve 1-1 character mapping but IMHO no generic solution
would do that, anyhow. I hope you find this technique useful/relevant.

enjoy,
Fotis


ps.
If you know *anybody* who has setup a database of build modes/instructions
for 1000s of software packages across architectures & OS platforms,
kindly pass on the information! (ie. something more reusable than pkgsrc)

N.B.
autoconf build processes are handled out-of-the-box by EB, here is an example:
https://github.com/hpcugent/easybuild-easyconfigs/blob/master/easybuild/easyconfigs/a/ABySS/ABySS-1.3.6-goolf-1.4.10-Python-2.7.5.eb

If you wonder why we bother with yet another build system, obviously,
you haven’t been debugging HPC environments for 100s of users; have fun reading this:
https://github.com/hpcugent/easybuild-easyblocks/blob/master/easybuild/easyblocks/b/boost.py