[Top][All Lists]

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

Re: False positive "doesn't match the target pattern" error

From: Alejandro Colomar
Subject: Re: False positive "doesn't match the target pattern" error
Date: Mon, 22 Aug 2022 20:08:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2

Hi David, Ingo,

For others starting to read this thread now, it started here:

On 8/22/22 16:46, David A. Wheeler wrote:

On Aug 22, 2022, at 12:02 AM, Alejandro Colomar <alx.manpages@gmail.com> wrote:

Hi David,

On 8/22/22 04:45, David A. Wheeler wrote:
On Aug 20, 2022, at 11:35 AM, Alejandro Colomar <alx.manpages@gmail.com> wrote:
I'd say there is:  make(1) treats file names as text strings, not really file 
names, for most of its operations.  As an example, foo/ and foo/. are different 
targets.  I don't see why ./bar and bar should be the same.  Consistency is 
essential; otherwise, what to expect?  Why does make(1) need to special-case a 
leading ./ ?
Because treating "./foo" and "foo" as different files is likely to lead to 
endless footguns.
Consistency is nice, but making something easy to use *correctly* is more important. I have no 
problem with special-casing "./XXX" as a synonym for "XXX"; anything else would 
be *unexpected* (if for no other reason than backwards compatibility).
As far as "foo/" vs. "foo/.", it's *much* less common to have directories as 
prerequisites or targets, so not handling them with special conveniences seems quite reasonable.

Is it so *much* less common?  I never really knew that make(1) treats ./foo and 
foo as the same thing until this bug report.  make(1) is (almost) very 
consistent in that it handles text, and not really file names.  But _all_ 
non-phony targets should declare a dependency like '|$$(@D)/', unless you can 
guarantee that it already exists by the time you'll try to create the file 
(e.g., when the file depends on another file in the same dir).

My Makefiles are plagued with that dependency, but a correctly-written Makefile 
shouldn't even notice that ./ is trimmed.

I also try to do that, but I think it'd backwards-incompatible if GNU make 
changed its current behavior.
I suspect a lot of makefiles would quietly work incorrectly if that change was 

Yeah, I guess the bug is resolving ./, and also that we will live forever with that bug.

Do other make(1) implementations trim this leading ./?

I tried on OpenBSD, and it seems to do that and more; it seems to be resolving symlinks and .. (physically, although I'm not yet sure of what it does to .. after segments of the path that don't exist). It doesn't seem to be documented, and also doesn't seem to be obvious in the source code (I can't find any realpath(3) calls, nor '..').

I wrote a program that behaves similar to how I think BSD make(1) behaves, after testing it a little bit:

$ cat canonicalizepath.c
#include <bsd/string.h>
#include <err.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char *canonicalizepath(const char *path);

main(int argc, char *argv[])
        int   ret;
        char *p;

        if (argc < 2)
                errx(EXIT_FAILURE, "missing operand");

        ret = EXIT_SUCCESS;

        for (ptrdiff_t i = 1; i < argc; i++) {
                p = canonicalizepath(argv[i]);
                if (!p) {
                        ret = EXIT_FAILURE;
                        warn("%s", argv[1]);
                } else {


char *
canonicalizepath(const char *path)
        char *cpy, *end, *sep, *p, *ret;
        size_t len;

        cpy = strdup(path);
        if (!cpy)
                return NULL;

        end = cpy + strlen(cpy);
        sep = end;

        do {
                *sep = '\0';

                p = realpath(cpy, NULL);
                if (p)
                        goto found;

                sep = strrchr(cpy, '/');
        } while (sep);

        sep = cpy;
        len = end - sep + 1;
        if (p)
                len += strlen(p);

        ret = malloc(len);
        if (!ret)
                goto fail;

        ret[0] = '\0';

        if (p)
                strlcat(ret, p, len);
        for (char *q = sep; q < end; q++) {
                if (*q == '\0')
                        *q = '/';
        strlcat(ret, sep, len);

        return ret;

alx@asus5775:~/tmp$ ./canonicalizepath .
alx@asus5775:~/tmp$ ./canonicalizepath ./foo/../asd
alx@asus5775:~/tmp$ ./canonicalizepath ./asd
alx@asus5775:~/tmp$ ./canonicalizepath asd
alx@asus5775:~/tmp$ ./canonicalizepath canonicalizepath
alx@asus5775:~/tmp$ ./canonicalizepath /home/../tmp/../../etc/

I don't think me want GNU make(1) to behave like that.

Ingo, do you know how your make(1) behaves with respect to '..', '//', '.', and symlinks? Is that documented anywhere?

No idea. However, I took a quick look at the POSIX make specification:

The POSIX specification for make is notoriously underpowered.
It doesn't say anything about whether or not ./FOO is the same as FOO.
It refers to files by PRECEDING them with "./", e.g.
"By default, the following files shall be tried in sequence: ./makefile and 
./Makefile. If neither ./makefile or ./Makefile are found, other implementation-defined 
files may also be tried. [XSI]   On XSI-conformant systems, the additional files 
./s.makefile, SCCS/s.makefile, ./s.Makefile, and SCCS/s.Makefile shall also be 
I interpret that as an expectation that adding "./" is expected to have the same
result if the filename starts with an alphabetic character, but that's
just my reading and not directly supported.

That refers to the input file, and not to targets within the DAG, AFAICS.



Alejandro Colomar

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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