On Sat, 2021-08-21 at 02:24 +0200, Steffen Nurpmeso via austin-group-l
at The Open Group wrote:
> Words like quick-dirty and hack i think are really displaced for
> the nice and elegant solution that .WAIT: is.
>
> I remember doing GNU make files and how i had to mess with stamp
> files in order to get at least a somehow reliable ordering.
> It may be some time but still.
Without knowing what you were trying to do all I can say is that the
entire PURPOSE of make is to impose a reliable ordering on the build.
I mean, you can just say:
foo: bar
and now you have a reliable ordering that bar will be completed before
foo can be started, regardless of how high your -j value is or where
else these targets appear in the makefile.
If that's not sufficient for some particular use-case (and it might not
be, as I discussed in my comments) then yes, more effort may be needed.
> .WAIT: is in use in the BSD world in their holistic makefile
> system for decades, and it enables people to write natural
> looking makefiles that can be understood at a glance, even after
> long work hours, and even after coming back to some project that
> has not been looked at in a long time.
Yes, I already said they're easy to read. But, they're easy to misuse
and misunderstand. Maybe that's a tradeoff that works fine in specific
situations (for example, BSD makefiles typically use .WAIT inside lists
of singleton "top level" targets like subdirectories so they don't run
into these issues because the targets only appear in only one target's
prerequisite list) but "easy to read and hard to use reliably" does not
make a great candidate for POSIX, at least IMO.
> Consider for example
>
> openssl/Makefile:SUBDIR= lib .WAIT bin
Why not just say:
bin: lib
?
> openssl/lib/Makefile:SUBDIR+= .WAIT libssl # depends
> on libcrypto
Why not just say:
libssl: libcrypto
? and now you don't even need the comment: it's self-documenting.
Also this form doesn't depend on the order that the SUBDIR variable was
created with: the .WAIT version doesn't actually say "you can only
build libssl after libcrypto", it says "everything before this point in
the SUBDIRS variable must be completed before libssl (and anything that
appears in SUBDIRS after libssl) can be started" which is a much
stronger, in fact probably stronger than necessary, statement.
In my opinion GNU make's solution:
bin: | lib
libssl: | libcrypto
is simply better. It describes precisely what the relationship is and
it is built into the dependency graph itself so takes effect wherever
these targets are used.
> Today it is only because of GNU make luckily supporting
> .NOTPARALLEL: that portable makefiles which can make use of -j
> can be written at all, _if_ following Wheeler's "everything can
> be done with an indirection", as shown in the introductional
> comment.
I find it quite unbelievable that the ONLY way to write a portable
makefile using -j is to use .NOTPARALLEL in GNU make.
I certainly would not be surprised to learn that this is a preferred
shortcut by folks who want to convert an existing BSD makefile that
uses .WAIT to be portable to GNU make, without actually changing the
makefile to use portable methods.
But, that is not the same thing.
> It seems to me GNU make could easily implement .WAIT:, even
> though with slightly different semantics, by creating a "pipe"
> rule of all prerequisites yet encountered on a line when
> a .WAIT is seen?
Well, everyone is welcome to their own opinion on the amount of effort
needed for this work: I've given mine.
I'll just point out, again, that the "create an internal rule" idea is
not something new which allows me to have a "eureka" moment where I
suddenly see a way to implement this feature in a few lines of code. I
mentioned this as a possible way forward in my comments in Dec 2020,
two days after the issue was filed.
If we really wanted to implement this the easiest possible way, it
would be simpler to implement like this: whenever a .WAIT target is
seen, GNU make pauses ALL new jobs and waits for all existing jobs to
complete before it proceeds. That would reduce the value of -j when
you use .WAIT but it would meet the requirements of the wording AFAICT.
