fix(make): exclude .NOTINTERMEDIATE from target completion

[15daksh-2003]

.NOTINTERMEDIATE (a GNU make 4.4 special target) was missing from the
extractor's special-target skip list, so it leaked into completion on a
dotted prefix like make .NOT<TAB> — a make directive, not a runnable
target. The hidden-target guard only suppresses dotted names on an empty
or trailing-/ prefix, so the explicit list is the sole filter for
specials under a dotted partial prefix.

Fix: add .NOTINTERMEDIATE to the list — a one-line, additive change,
with a regression test/fixture. .WAIT and .EXTRA_PREREQS are
deliberately not added: .WAIT is a parse-consumed prerequisite marker
and .EXTRA_PREREQS is a variable, so neither surfaces as a target block.

Follow-up from the #1693 review.

[15daksh-2003]

@akinomyoga here for engagement on this

[akinomyoga]

.WAIT is a parse-consumed prerequisite marker

The GNU make manual says

You can create an actual target .WAIT in your makefile for portability but this is not required to use this feature. If a .WAIT target is created it should not have prerequisites or commands.

It seems to imply that .WAIT may be listed by older versions of GNU make when the user adds the prerequisite .WAIT to work around the "unknown target" error in the older versions of GNU make. I also confirmed that, even in the newer versions of GNU make, when the .WAIT prerequisite is present in Makefile/GNUmakefile, .WAIT is listed in make -npq. I believe those workaround prerequisites .WAIT should be excluded anyway.

[15daksh-2003]

The GNU make manual says

You can create an actual target .WAIT in your makefile for portability but this is not required to use this feature. If a .WAIT target is created it should not have prerequisites or commands.

It seems to imply that .WAIT may be listed by older versions of GNU make when the user adds the prerequisite .WAIT to work around the "unknown target" error in the older versions of GNU make. I also confirmed that, even in the newer versions of GNU make, when the .WAIT prerequisite is present in Makefile/GNUmakefile, .WAIT is listed in make -npq. I believe those workaround prerequisites .WAIT should be excluded anyway.

makes sense. included it

[akinomyoga]

For the existing if (/^\.MAKE:/ ) next;, GNU make doesn't seem to recognize .MAKE (or at least it doesn't describe it in its manual). The .MAKE seems to be a special target written for BSD make, but BSD make seems to have more special sources and targets. Should we also include these for consistency?

[15daksh-2003]

For the existing if (/^\.MAKE:/ ) next;, GNU make doesn't seem to recognize .MAKE (or at least it doesn't describe it in its manual). The .MAKE seems to be a special target written for BSD make, but BSD make seems to have more special sources and targets. Should we also include these for consistency?

even before that I found something interesting: the manual's --print-targets section says it excludes "special targets (target names consisting of . followed by all upper-case letters)."...makes me think why do we need to define the special targets all explicitly. why not pattern based approach here? This needs a bit of thinking I think for nuances.

[15daksh-2003]

as for the BSD make special targets...I was checking if there is any rationale behind why and how .MAKE and so got introduced in the project for special targets. This seems to have been added in 2012...not sure if while adding this there was a GNU specific rationale...

[15daksh-2003]

but yeah...print targets or so itself would land in 4.5....

[15daksh-2003]

even before that I found something interesting: the manual's --print-targets section says it excludes "special targets (target names consisting of . followed by all upper-case letters)."...makes me think why do we need to define the special targets all explicitly. why not pattern based approach here? This needs a bit of thinking I think for nuances.

from the code, it seems the awk runs in the user locale. for something like a pattern, awk [A-Z] is a collation range (can match lowercase in case-interleaving locales → silently drop a real target). one good analogue could be [[:upper:]]

also from what make's defined approach for print_targets is....it does not seem to take into account specials with underscores like .DELETE_ON_ERROR, .LOW_RESOLUTION_TIME, .EXPORT_ALL_VARIABLES.... something that ^.[A-Z]+$ won't match

[15daksh-2003]

as for the BSD make special targets...I was checking if there is any rationale behind why and how .MAKE and so got introduced in the project for special targets. This seems to have been added in 2012...not sure if while adding this there was a GNU specific rationale...

For the existing if (/^\.MAKE:/ ) next;, GNU make doesn't seem to recognize .MAKE (or at least it doesn't describe it in its manual). The .MAKE seems to be a special target written for BSD make, but BSD make seems to have more special sources and targets. Should we also include these for consistency?

also, while checking on this further....NOEXPORT also seems obsolete and redundant sort of... from I think 4.9 section of manual. further BSD -p seems to have a different shape altogether, whereas our parser seems to be catering to GNU only. Extending...might be a rabbit hole .....

[15daksh-2003]

even before that I found something interesting: the manual's --print-targets section says it excludes "special targets (target names consisting of . followed by all upper-case letters)."...makes me think why do we need to define the special targets all explicitly. why not pattern based approach here? This needs a bit of thinking I think for nuances.

from the code, it seems the awk runs in the user locale. for something like a pattern, awk [A-Z] is a collation range (can match lowercase in case-interleaving locales → silently drop a real target). one good analogue could be [[:upper:]]

also from what make's defined approach for print_targets is....it does not seem to take into account specials with underscores like .DELETE_ON_ERROR, .LOW_RESOLUTION_TIME, .EXPORT_ALL_VARIABLES.... something that ^.[A-Z]+$ won't match

I got the code snippet as this:

static void
print_target (const void *item)
{
  const struct file *f = item;

  if (!f->is_target || f->suffix)
    return;

  /* Ignore any special targets, as defined by POSIX. */
  if (f->name[0] == '.' && isupper ((unsigned char)f->name[1]))
    {
      const char *cp = f->name + 1;
      while (*(++cp) != '\0')
        if (!isupper ((unsigned char)*cp))
          break;
      if (*cp == '\0')
        return;
    }

  puts (f->name);
}

void
print_targets (void)
{
  hash_map (&files, print_target);
}

[15daksh-2003]

@akinomyoga for thoughts on these thingy. mostly because of underscore specials...I think staying on list only is good for now

[akinomyoga]

In general, Makefile can be designed to be compatible with both GNU and BSD variants of make. Such a Makefile may contain the targets that have meanings in a make implementation and are ignored in the other make implementions. In principle, those targets should be excluded regardless of whether GNU make interprets it as a special target. However, although I'm not sure why only .MAKE from BSD make was excluded in the present script, I think we don't have to care about BSD special targets too much.

The character range of A-Z is not a relevant issue because we can set LC_COLLATE=C to take care of it.

The target .NOEXPORT seems to have been supported by very old versions of GNU make, and autotools (which is known to be excessively backward compatible) seems to still generate such a target. Then, it is reasonable to continue supporting exclusion of it.

[15daksh-2003]

In general, Makefile can be designed to be compatible with both GNU and BSD variants of make. Such a Makefile may contain the targets that have meanings in a make implementation and are ignored in the other make implementions. In principle, those targets should be excluded regardless of whether GNU make interprets it as a special target. However, although I'm not sure why only .MAKE from BSD make was excluded in the present script, I think we don't have to care about BSD special targets too much.

makes sense

The character range of A-Z is not a relevant issue because we can set LC_COLLATE=C to take care of it.

since we r going with list, i think this only comes into picture for pattern based approach..we can drop thinking on this

The target .NOEXPORT seems to have been supported by very old versions of GNU make, and autotools (which is known to be excessively backward compatible) seems to still generate such a target. Then, it is reasonable to continue supporting exclusion of it.

makes sense

[15daksh-2003]

@akinomyoga should we merge this?

[akinomyoga]

I would like input from another maintainer.

[yedayak]

Looks fine to me