[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnu-prog-discuss] Blog Post Sighting: Autotools Considered Harmful

From: Paul Smith
Subject: Re: [gnu-prog-discuss] Blog Post Sighting: Autotools Considered Harmful
Date: Mon, 10 Jul 2023 14:55:13 -0400
User-agent: Evolution 3.48.3 (by Flathub.org)

On Mon, 2023-07-10 at 12:56 -0400, Stefan Monnier wrote:
> > There ARE things we could do with GNU Make still that would make it
> > more useful, and faster in some situations, without throwing away
> > the millions of existing makefiles and the knowledgebase.  I
> > maintain a list of them so if this kind of works tickles your
> > fancy, or you have idea of your own and want to discuss them with
> > very knowledgeable people I recommend discussing it on the bug-
> > make@gnu.org mailing list.
> My main gripe with Make is the absence of good quoting rules, which
> makes it almost impossible to work with files whose names include
> funny characters like spaces or colons.

There was a long thread a number of years ago with an idea I had for
how to handle this.  I wasn't able to really convince people that my
idea would work :).

I was suggesting that there be a new type of "word quoting" in GNU
Make, maybe something like $[some:text here] or something like that. 
The content within that quoting would be omitted from all types of
parsing by the GNU Make parser, including both for special characters
AND for word breaks (that is, the text would be considered a single
word for all word-based functions like filter, foreach, etc. etc.  Of
course we have to decide how to allow "]" (or whatever) in such a
string :-p :-(

The results of $(wildcard ...) or other globbing would automatically be
marked as this type of "atomic word" of course.

This would make it possible to work with difficult filenames, but with
a cost of having to apply this extra markup.  Also based on the
implementation I had in mind, some UTF-8 control characters would no
longer be allowed to appear in makefiles.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]