Re: [RFC PATCH v4 00/19] Modernize the build system
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Oct 24, 2024, 16:02 UTC
- Message-ID
- <ZxpvlvafLlmXbgpA@nand.local>
- In-Reply-To
- <cover.1729771605.git.ps@pks.im>
On Thu, Oct 24, 2024 at 02:39:43PM +0200, Patrick Steinhardt wrote:
Show 23 quoted lines
> - The last patch is a compatibility patch for "seen". There are a > couple of topics that interact with this series, and I didn't want > to make all of them a strict dependency. So I've decided to just > create a fixup-style commit that does the necessary changes in order > to work with "seen". Like this, you can test without "seen" by > simply dropping that last commit, and you can test with "seen" by > merging it into this topic. > > @Taylor: I didn't really have a better idea than this. There are > six additional topics that this branch interacts with, and building > the branch with eight dependencies in total didn't feel sensible. > Ideally, the topic branch itself shouldn't have the last commit, but > once it gets merged into 'seen' we should have it. Let me know in > case you have a better idea though. > > This topic is built on top of fd3785337b (The third batch, 2024-10-22) > with the following two branches merged into it: > > - ps/upgrade-clar at 30bf9f0aaa (cmake: set up proper dependencies for > generated clar headers, 2024-10-21). This is currently in 'seen'. > > - ps/platform-compat-fixes at 80ebd91b83 (http: fix build error on > FreeBSD, 2024-10-16). This has been merged to 'next'.
Thanks for all of the helpful information. I changed the base up to "The third batch" and merged in the two branches you mentioned. Everything builds fine at the tip and passes 'make test'.
Show 7 quoted lines
> I was pondering a bit whether I should split this topic up even further. > I've already evicted other parts out of it such that they can land > separately, and landing the Makefile refactorings independently would > reduce the overall review load. These steps also make sense even if we > don't have Meson, as those are all either simplifications, improvements > for CMake or a necessary step towards out-of-tree builds. Let me know > your thoughts!
I think erring on the side of smaller series makes them easier to review, as Stolee and I were talking about in another thread. But if you feel like this topic is receiving sufficient review as-is, then I wouldn't bother changing it.
Thanks, Taylor