Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong info found: $* #2

Closed
mjy9088 opened this issue Jun 17, 2023 · 1 comment
Closed

Wrong info found: $* #2

mjy9088 opened this issue Jun 17, 2023 · 1 comment

Comments

@mjy9088
Copy link
Contributor

mjy9088 commented Jun 17, 2023

The $* macro shall evaluate to the current target name with its suffix deleted. It shall be evaluated at least for inference rules.

Your description The stem that matched the pattern of a rule is wrong.

mjy9088 added a commit to my-organization-for-forks/Make-A-Make that referenced this issue Jun 17, 2023
@mjy9088
Copy link
Contributor Author

mjy9088 commented Jun 17, 2023

I found GNU Make manual states:

The stem with which an implicit rule matches (see How Patterns Match). If the target is dir/a.foo.b and the target pattern is a.%.b then the stem is dir/foo. The stem is useful for constructing names of related files.
In a static pattern rule, the stem is part of the file name that matched the ‘%’ in the target pattern.
In an explicit rule, there is no stem; so ‘$’ cannot be determined in that way. Instead, if the target name ends with a recognized suffix (see Old-Fashioned Suffix Rules), ‘$’ is set to the target name minus the suffix. For example, if the target name is ‘foo.c’, then ‘$’ is set to ‘foo’, since ‘.c’ is a suffix. GNU make does this bizarre thing only for compatibility with other implementations of make. You should generally avoid using ‘$’ except in implicit rules or static pattern rules.
If the target name in an explicit rule does not end with a recognized suffix, ‘$*’ is set to the empty string for that rule.

I think GNU Make is not POSIX-compliant when Makefile uses %.

Nuno-Jesus added a commit that referenced this issue Jun 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant