<div dir="ltr">> The FreeBSD graph is a fully recursive "all dependencies" graph, both for<br>> building and running, the debian graph seems to be truncated somehow,<br>> because otherwise that would be a very handicapped py3 instance.<div><br></div><div>My bad, I was only considering the run dependencies, the build+run dependency list is bigger.</div><div><br></div><div>BUT! I dug a bit, and the insanity is really only introduced by the test dependency on devel/py-pytest-xdist, snip it and meson+ninja only need 33 ports, which isn't that crazy when compared with the 20 items in the automake+autotools+autoconf+libtool case.</div><div>Now, I have now idea if that detail matters or not, as I'm not a freeBSD, but hopefully that number isn't as shocking anymore.</div><div><br></div><div>> If all you use make(1) for is running processes, it's as good as anything</div>> (except maybe jam(1)).  The hard part about make(1) is getting _all_<br>> your dependencies recorded _correctly_ in the makefile.<div><br></div><div>That's the biggest footgun of make because it doesn't know about recipes producing multiple files (and we do love those), so you have to bend over backwards to teach it how to do it correctly. Add to this the dumb recursive mode, its lack of dependency regarding the build commands and all the dark magic it *tries* to accomplish to handle C compilation correctly (I'd rather have something truly dumb that doesn't get in the way) and you get a nice recipe (pun intended) for disaster.</div><div><br></div><div>I don't know jam and so have no problem with it. Since you talked about the generator+builder pattern, I feel like i need to link to this very recent post: <a href="http://neugierig.org/software/blog/2020/05/ninja.html">http://neugierig.org/software/blog/2020/05/ninja.html</a> It's from the ninja creator, where he writes about it a bit (and also apologies for the terrible name).</div><div><br><div><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br></div>Guillaume Quintard<br></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 14, 2020 at 9:25 AM Poul-Henning Kamp <<a href="mailto:phk@phk.freebsd.dk" target="_blank">phk@phk.freebsd.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">--------<br>
In message <<a href="mailto:CAJ6ZYQxTCZO7gS0_o7iehr2gYOJ58XKheOaPxW1zSRO68hfK9w@mail.gmail.com" target="_blank">CAJ6ZYQxTCZO7gS0_o7iehr2gYOJ58XKheOaPxW1zSRO68hfK9w@mail.gmail.com</a>><br>
, Guillaume Quintard writes:<br>
<br>
>I'm going to vote for "that freeBSD port is absolutely bonkers and probably<br>
>deserves the behind-the-barn treatment", specially considering the debian<br>
>dependency graph: <a href="https://ibb.co/YdXMHRZ" rel="noreferrer" target="_blank">https://ibb.co/YdXMHRZ</a><br>
<br>
The FreeBSD graph is a fully recursive "all dependencies" graph, both for<br>
building and running, the debian graph seems to be truncated somehow,<br>
because otherwise that would be a very handicapped py3 instance.<br>
<br>
And as I said: meson is probably not to blame, I just wanted to illustrate<br>
my concern.<br>
<br>
>I'm not fully against rolling out our own system, but for the love of all<br>
>that is holy, let's not base it on Make.<br>
<br>
If all you use make(1) for is running processes, it's as good as anything<br>
(except maybe jam(1)).  The hard part about make(1) is getting _all_<br>
your dependencies recorded _correctly_ in the makefile.<br>
<br>
-- <br>
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20<br>
phk@FreeBSD.ORG         | TCP/IP since RFC 956<br>
FreeBSD committer       | BSD since 4.3-tahoe    <br>
Never attribute to malice what can adequately be explained by incompetence.<br>
</blockquote></div>