bug-make
[Top][All Lists]
Advanced

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

Re: goals starting with a period followed by a slash


From: Paul Smith
Subject: Re: goals starting with a period followed by a slash
Date: Thu, 02 Feb 2017 11:36:18 -0500

On Thu, 2017-02-02 at 16:53 +0100, Stefan Tauner wrote:
> I don't know why it behaves differently with slashes in the goal and
> would love to hear a rationale for that (and it being mentioned in
> the documentation ;)
> The current documentation reads as follows (emphasis mine):
> > By default, the goal is the first target in the makefile (*not
> > counting targets that start with a period*).

The documentation is wrong (or rather, incomplete).  It's intended to
state that special targets are not considered as default targets.

The POSIX spec defines special targets as "targets with names
consisting of a leading <period> followed by one or more uppercase
letters".

In GNU make we extend the characters that may appear in special targets
to include underscores, I think.

But we don't allow slashes in special targets, so any target that
contains a slash is not a special target, and will be used as the
default target.

> Also, I think there is a bug related to this that truncates the
> target name in the front. Suppose the following makefile:
> 
> ./tmp/dot:
>         touch $@
> 
> useless:
>         touch $@
> 
> According to the documentation simply running "make" should execute
> the "useless" recipe and create a file named "useless" in the CWD.
> However, since the check above sees the dot goal as a legitimate
> target it tries to execute it... however something with the target
> name is wrong.

This is intended behavior; it allows you to use "foo" and "./foo"
interchangeably as targets/prerequisites and for make to understand
that they're the same thing.

There is a bug filed about this (or maybe two) so we may try to change
the behavior (for example to keep the "./" in the version of the path
that's used in automatic variables).

But, the behavior itself isn't a bug.



reply via email to

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