Re: [hackers] [farbfeld] Makefile-workaround for OpenBSD || Laslo Hunhold

2017-05-29 Thread Hiltjo Posthuma
On Mon, May 29, 2017 at 07:15:15PM +0200, Laslo Hunhold wrote:
>
> As far as I can see it, we are left to write down each target
> explicitly.

Which is not an issue in my opinion in our case.

Like I said on IRC:

Generally speaking I'd prefer if the Makefile is 20 lines longer and
very straightforward to read than only a few complex lines that depends
on certain behaviour which is not implemented consistent in each make
implementation. Even if it is POSIX correct (or not).

But that's just like, my opinion, man.

-- 
Kind regards,
Hiltjo



Re: [hackers] [farbfeld] Makefile-workaround for OpenBSD || Laslo Hunhold

2017-05-29 Thread Laslo Hunhold
On Mon, 29 May 2017 18:46:53 +0200
Quentin Rameau  wrote:

>

The essence of the problem is this sentence in the spec[0]:

"A target that has prerequisites, but does not have any
 commands, __can__ be used to add to the prerequisite list for
 that target. Only one target rule for any given target can
 contain commands."

Thus, we cannot depend on the behaviour that make adds $(BIN).o to the
list of prerequisites within the $(BIN) target.

As far as I can see it, we are left to write down each target
explicitly.

With best regards

Laslo Hunhold

[0]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html

-- 
Laslo Hunhold 



Re: [hackers] [farbfeld] Makefile-workaround for OpenBSD || Laslo Hunhold

2017-05-29 Thread Laslo Hunhold
On Mon, 29 May 2017 18:46:53 +0200
Quentin Rameau  wrote:

Hey Quentin,

> Well, I've been warning you with the first patch long ago.

yes, and admittedly, even though it was a painful process, I learned a
lot about make and how sadly infested the ecosystem is with GNU
extensions.

> The issue is that OpenBSD make doesn't take in account the inference
> rule because of the added silent dependency.
> It looks a lot like it's an obsd make issue, I didn't personally took
> too much time to go through the source when the issue arose two months
> ago. 

Well, in POSIX-speak from the reference:

"If the target to be built does not contain a suffix and there
 is no rule for the target, the single suffix inference rules
 shall be checked. The single-suffix inference rules define how
 to build a target if a file is found with a name that matches
 the target name with one of the single suffixes appended. A
 rule with one suffix .s2 is the definition of how to build
 target from target.s2. The other suffix (.s1) is treated as
 null."

This clearly shows that OpenBSD is not violating POSIX here. I think
though it's a shame that single suffix rules are treated as second
class citizens here.
This "inconsistency" in the standard has been filled out by the other
implementations which is the reason why it has gone unnoticed until
Hiltjo pointed it out to me.

If you have any suggestions to solve this elegantly, please let me know.

I know it's a mountain of work, but a "suckless" make implementation
without extensions, which is just following the POSIX spec, would be
really cool.

With best regards

Laslo Hunhold

-- 
Laslo Hunhold 



Re: [hackers] [farbfeld] Makefile-workaround for OpenBSD || Laslo Hunhold

2017-05-29 Thread Quentin Rameau
> Makefile-workaround for OpenBSD

At last!

> Thanks Hiltjo for reporting this!

Well, I've been warning you with the first patch long ago.

> For some reason, OpenBSD make does not add $(BIN).o to the
> dependency list when it sees the $(BIN) target rule. It does so
> however when it does the conversion from .c to .o.
> This behaviour is unique for OpenBSD make as far as I've seen,
> and for the time being, this workaround will manually add the object
> to the dependency list.
> This is not POSIX compliant and in GNU make it just evaluates to
> an empty string, but it works until this has been investigated
> further.

The issue is that OpenBSD make doesn't take in account the inference
rule because of the added silent dependency.
It looks a lot like it's an obsd make issue, I didn't personally took
too much time to go through the source when the issue arose two months
ago.