On Sun, 2 Apr 2017 15:16:40 -0300
Lucas Gabriel Vuotto <lvuotto92_AT_gmail.com> wrote:
Hey Lucas,
thanks for taking your time to put together a response. I really
appreciate it!
> From [0], extended description, inference rules:
>
> «The application shall ensure that the target portion is a valid
> target name (see Target Rules) of the form .s2 or .s1.s2 (where .s1
> and .s2 are suffixes that have been given as prerequisites of
> the .SUFFIXES special target and s1 and s2 do not contain any <slash>
> or <period> characters.) If there is only one <period> in the target,
> it is a single-suffix inference rule. Targets with two periods are
> double-suffix inference rules. Inference rules can have only one
> target before the <colon>.
Up to this point we are fine.
> The application shall ensure that the makefile does not specify
> prerequisites for inference rules;
Re-checking the Makefile, I think we are fine if I remove the
$(REQ:=.o) from the .o inference rule, given this dependency is already
listed for each $(BIN).
> no characters other than white space shall follow the <colon> in the
> first line, except when creating the empty rule, described below.
> Prerequisites are inferred, as described below.
That works as well.
> I'm talking about $($*-LDFLAGS). From [0], extended description,
> macros:
>
> «Macros can appear anywhere in the makefile. Macro expansions using
> the forms $(string1) or ${ string1} shall be replaced by string2, as
> follows: [...] The parentheses or braces are optional if string1 is a
> single character. The macro $$ shall be replaced by the single
> character '$'. If string1 in a macro expansion contains a macro
> expansion, the results are unspecified.»
Thanks for pointing that out! Quentin's proposition does not solve this
problem though, he's using $($_AT_-LDFLAGS), and I think it's quite fair to
assume that any implementation out there is capable of working out what
$($*-LDFLAGS)
means. After all, $* is a built-in macro and not something too crazy,
which is probably the reason why it has been left unspecified given how
versatile makefile-macros can be. You are perfectly right though, which
I don't want to understate here, though I think it's a fair compromise
to keep it in this case given we only really expand a built-in macro.
I know Quentin's solution can be altered to avoid the unspecified
behaviour, but this in my opinion complicates the makefile too much.
> No, it won't. In order to override a macro *defined* in the makefile
> with an environment variable, make must be invoked with the `-e`
> flag. Even more correct is to call `make CC=...`, as macros defined
> in the command line override everything. All that defined is in [0],
> extended description, macros.
Sorry for being unclear about what I meant. I'll still keep it, given
it's common practice among all suckless projects and I've found it to
be pretty handy in some cases. Thanks for clearing it up.
> I don't see a reason for wasting time making the Makefile POSIX
> compliant but not the full build chain.
What do you suppose to be the build chain in this context? Are you
talking about the assumption of "cc" existing? Well, anyway, I just
noticed that I missed something. Given I use stdint.h I have to use C99
instead of C89. I'll include that in an upcoming commit.
> I hope this mail makes things clearer to you.
Yes it did! Thanks for the clear words and references to the standard.
I think it's a shame that most resources on the web on Makefiles are
littered with GNU make specific content.
It might be an interesting exercise to write an article on common
pitfalls that should be avoided when writing standard compliant
makefiles.
With best regards
Laslo Hunhold
--
Laslo Hunhold <dev_AT_frign.de>
Received on Sun Apr 02 2017 - 20:51:48 CEST