tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Minor annoyance with bmake



Am 04.05.2019 um 17:59 schrieb Jason Bacon:
> There's been an intermittent issue running multiple targets with bmake
> for as long as I can remember:
>
> Sometimes only the first target runs and sometimes all targets work.

It's not really sometimes. It's only surprising when any of the "clean"
targets is involved.

There are several occurrences of the following code, such as in
mk/depends/depends.mk:

.  if exists(${_COOKIE.depends})
depends:
	@${DO_NADA}
.  else
depends: ${_DEPENDS_TARGETS}
.  endif

This code assumes that the "exists" won't change during the run, and
that it certainly doesn't go backwards from "exists" to "doesn't exist
anymore". This assumption is wrong though.

To test this, I modified the condition in that file, which occurs twice:

.  if exists(${_COOKIE.depends}) && !make(clean)

After this little change everything works as you expect. As a test
package I chose sysutils/checkperms since that one is built very early,
it has almost no dependencies and no patches.

bmake clean depends
bmake clean depends
bmake clean depends
bmake clean depends

Now the output is the same each time.

And now to the fineprint. There are of course multiple targets that
clean something. Off the top of my head, that's clean, pre-clean,
do-clean, post-clean, cleandepends, distclean. I'm sure I forgot some.

I think it would be an improvement to have a variable called _CLEANING
defined somewhere very early in bsd.prefs.mk that becomes "yes" if one
of the "clean" targets is in the command line. This would already help
for "bmake clean depends".

But what about "bmake depends clean"? It really depends on the ordering.
To implement this correctly, there should be some oracle that answers
"does any clean target come before the depends target"?

What about "bmake clean update clean update", which might be used for
checking whether a package builds reproducibly?

All this is certainly a non-trivial task. But it would indeed be nice to
get rid of this surprising behavior. Even if it would be only a 99%
solution.


Home | Main Index | Thread Index | Old Index