Hi Laslo
On 02/04/17 13:16, Laslo Hunhold wrote:
> On Sat, 1 Apr 2017 00:49:15 -0300
> Lucas Gabriel Vuotto <lvuotto92_AT_gmail.com> wrote:
>
> Hey Lucas,
>
>>> -.o: $(REQ:=.o)
>>> - $(CC) $(LDFLAGS) $($*-LDFLAGS) -o $_AT_ $< $(REQ:=.o)
>>> +$(BIN): $(REQ:=.o)
>>>
>>> $(BIN:=.o): config.mk $(HDR) $(REQ:=.h)
>>>
>>> +.o: $(REQ:=.o)
>>> + $(CC) $(LDFLAGS) $($*-LDFLAGS) -o $_AT_ $< $(REQ:=.o)
>>
>> This is a recipe for the file `.o'. I'm certain that you don't want
>> to do that.
>
> No, this is not a recipe for the file ".o". This is a single suffix
> rule for transforming objects into binaries.
> Now, I know this is not the most beautiful solution, but in this case
> every binary should include the requisite-objects, as every binary is
> using util.h in one way or another.
> I am certain that I want to do that.
>
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>.
The application shall ensure that the makefile does not specify
prerequisites for inference rules; 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.»
>> Also, expanding macros inside macros produces undefined results. The
>> proposed patch by Quentin is correct solution [0].
>>
>> [0]: http://lists.suckless.org/hackers/1703/14849.html
>
> Okay, first off. Please tell me where my Makefile is broken
> feature-wise. I'm struggling to find the problem.
I never said it was broken feature-wise; it's only non-compliant.
> Keep in mind, that for explicit single suffix rules make is smart
> enough to include the .o in the dependency tree. There's no need to
> list it explicitly.
>
That's right.
> Secondly, where in my Makefile am I triggering undefined results? Are
> you talking about "$($*-LDFLAGS)"? As you know, I'd love to know.
>
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.»
>> Beside that, you're overriding CC in config.mk with a non-standard
>> binary and compiling against c89 for some reason. That goes against
>> the idea of making the Makefile POSIX imo.
>
> It's a convenience you'll find in every suckless Makefile and even
> beyond that. It's common to provide a command within the Makefile, or
> in this case the config.mk, to override the standard C compiler.
> "cc" is actually common in Unix systems and points at the default C
> compiler.
> If you run make with a envvar-prefix "CC=..." it will respect that.
>
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.
> The code is ANSI C (C89, C90 call it however you like), which is why I
> point it out here to the compiler. There's nothing wrong with that.
> What's your point?
>
I don't see a reason for wasting time making the Makefile POSIX
compliant but not the full build chain.
>> I suggest you either do as Hiltjo says and revert everything or make
>> the build system completely POSIX. Right now, it's an ugly hybrid.
>
> Except from your remark about the undefined behaviour which I'm very
> interested to see what you mean, the Makefile as is seems to be POSIX
> compliant to me. I hope you can help me in case I am wrong about it.
>
> With best regards
>
> Laslo Hunhold
>
I hope this mail makes things clearer to you.
Cheers.
[0]:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
-- lv.
Received on Sun Apr 02 2017 - 20:16:40 CEST