> I don't think make can be expected to handle spaces in filenames
> because by design it relies on many other tools and scripts that
> cannot handle them or handle them in very idiosyncratic ways.
> You're in for a lot of trouble regardless of what make itself supports.
> Most Unix scripters know this before they even meet make, so they
> will already avoid using spaces (or other shell metacharacters) in
> filenames with make.
This is a piece of inertia obstructing the adoption of Unixish systems,
notably Linux. Software in the modern world should cope with path names
that include spaces and (most) non-ASCII characters - if only for the
boringly simple reason that the user's home directory may have them in
its name, for example if the corporate policy gives everyone a share on
the SAN using their full name (which, outside the anglophone world,
commonly isn't naturally written in ASCII). The corporate sysadmins set
everything up assuming a certain non-free OS which can cope with space
in file-names; and the employee who wants to use Ubuntu gets skewered by
scripts on Unixish systems not being able to cope with spaces in the
filenames.
Equally, when management has prioritised support for a non-free OS, the
software being developed may well be all set up to build with the IDE
provided by the OS vendor, which copes fine with spaces in filenames, so
the developers are apt to use spaces in paths. The few developers who
want to add support for a free OS are then left to skunk together a way
to get make to build the software; and make's inability to cope with
spaces is going to make that harder than it needs to be. Asking the
rest of the team to not use spaces in directory names is just one more
way to reinforce their prejudice that an OS that doesn't come from a big
corporate monopolist is obviously lame and not worth taking seriously.
The more software there is that doesn't get ported to Linux, the more
effectively the "application barrier to entry" keeps Linux out:
businesses that might otherwise switch are put off by the lack, on
Linux, of an application they're used to. Switching to an "equivalent",
even when one is available, is always a greater cost than switching to a
port of what their staff are already used to and their IT infrastructure
is already set up to work with.
One can usually work round such problems (e.g. by judicious use of
symlinks and relative paths), but we shouldn't take for granted that we
can make users do extra work in order to use a free OS - any more than
we should we take for granted that Linux is for experts, the classic way
to ensure it stays a minority OS. So I take issue with treating "can't
handle spaces" as a non-issue. The fact that it breaks many tools on
Unixish systems is an obstacle to adoption: I exhort all those who would
foster free software to dilligently pay attention to the possibility of
spaces in file-names and treat "can't handle spaces" as a bug, to be
fixed wherever possible.
In most cases, that just means being systematic about using quotes
properly (and related things like using "$@" instead of $* in the shell
scripts); but I'm afraid it's not a fixable issue in make. Then again,
I think we do complex enough things these days that it's time to replace
make - it's done pretty well for a long time, but software development
has increased hugely in complexity in that time - albeit the offerings
I've seen to date, that claim to replace or improve on make, have
generally disappointed (typically, they reveal that their author didn't
understand what make can in fact do; they think they've improved on it,
but actually can't do much of what make can and can't do anything
significant that make can't; their main "benefit" is providing explicit
support for something the author never worked out how to do in make).
One exception, written by one of my former colleagues, is slowly being
worked (behind closed doors, where I can't get at it to help) into a
state where our former employer might let it get released as open source
- I'll be sure to post here if and when that happens, but don't hold
your breath.
I concede that fixing this in make is probably asking for too much: but
plese don't take for granted that failure to support spaces is not a
problem. It's one of those little things that makes life harder for
those migrating from an OS which handles spaces routinely; and those
little things add up to an obstacle; they do give corporate suits the
excuse they're secretly waiting for to abandon the migration that might
otherwise have happened.
Eddy.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
