On Fri, Oct 18, 2024 at 05:08:41PM +0100, Ramsay Jones wrote:
> On 18/10/2024 13:23, Patrick Steinhardt wrote:
> > Hi,
> >
> > this is the third version of my patch series that aims to modernize our
> > build system infrastructure. It refactors our existing build infra to be
> > ready for out-of-tree builds and then wires up Meson.
> >
> > Changes compared to v2:
> >
> > - I have split out semi-related changes like the platform
> > compatibility fixes into separate series. More on that further down
> > below, where I explain the current base.
> >
> > - I have polished the CMake-related changes I've been doing as prereqs
> > while refactoring our build system. Some of the changes weren't
> > tested before, but now CMake works as expected.
>
> Just curious, does the cmake build system work on Linux now?
>
> (cmake is another system that I don't really know, except in a
> 'monkey-see monkey-do' kinda way)
To some extent. Some issues have been fixed and/or improved by this
series, but we're not fully there for CMake:
- It builds, but the build leaks outside of the build directory into
the source tree. In theory we now have all parts together to fix
that, as demonstrated by the Meson build support, but I didn't wire
this up.
- The tests do not run at all for me, might be I'm holding it wrong.
But with the patch that allows us to override the GIT-BUILD-DIR we
should be able to get out-of-tree tests running, as well. Again, I
didn't wire this up.
- Some things simply haven't been wired up at all, like building
"gitweb.cgi". Any gitweb-tests would thus fail.
But in any case, this patch series doesn't regress support for CMake
anymore like previous versions did.
> > - Fixed up some dependencies in our Makefile, as I didn't amend them
> > to depend on the new generator scripts.
> >
> > - I have extracted some more scripts to massage our Perl library code,
> > shells cripts and gitweb.cgi such that they can be used by Make,
> > CMake and Meson. This also fixes generation of "gitweb.cgi" on
> > Meson as reported by Ramsay.
>
> I haven't had time to test this yet (I haven't even properly read the
> patches), but from a quick squint, this looks similar to my attempts
> to do the same thing the other night (minus the cmake stuff, of course).
>
> However, I didn't notice anything in the commit message about changing
> the format of the GITWEB-BUILD-OPTIONS file, which already exists before
> that commit. I did the same, btw, but it seems that file was only used to
> 'notice' when the configuration changed to enable the re-build of gitweb.cgi.
> In which case, the change in format (rather than content) was not an issue.
Yeah, it's been a bit weird before. It contained sed commands to
execute, but also some other relevant build options. Made this whole
thing a bit weird to use.
In any case, it works the same way that GIT-BUILD-OPTIONS work now,
which I think is a good thing. The plumbing around it is a bit verbose,
but other than that I think it's straight-forward.
> >
> > - I have fixed the cyclic dependency in our Makefile that I have
> > introduced with v2.
> >
> > - I have addressed some feedback regarding "build-systems.txt".
> >
> > - I have made things work with OpenBSD 7.6.
> >
> > - Things now work on Cygwin and MinGW64 as expected, no more test
> > failures except for t9700, which also fails with our Makefile.
>
> This caused me some concern for a little while, since I don't recall
> that the t9700 test has ever failed for me on cygwin. I have the test
> output files for all versions of git (each rc and rel) from v2.12.0-rc0
> (5th Feb 2017) to today (all 143 of them) and none of them show that
> test failing. (I remove files from that directory on occasion when it
> takes up too much disk space).
>
> However, you qualify that statement in the commit message to make clear
> that it works on cygwin, but fails on other windows 'targets'. phew! :)
Oh, yeah, that one seems misleading indeed.
> > - I have improved how we set up the required tooling on Windows such
> > that we detect Git for Windows-provided tools as we do with CMake.
> > Like this, VS Code can now trivially import the Meson project and
> > configure it. Furthermore, generation of the Visual Studio solution
> > is trivial as well. So overall, things work fine now on all the
> > important Windows environments that I'm aware of.
> >
> > - Several smaller fixes all over the place.
> >
> > I've included a range-diff, but it's quite crowded overall.
> >
> > In general I think that this is in a pretty good shape now. I have
> > tested things on NixOS, macOS 10.15, OpenBSD 7.6, FreeBSD 14.1, Windows
> > 10 with MSVC, VS Code, MinGW and Cygwin, and things are generally smooth
> > and just work. I'm sure there's still going to be weirdnesses on some
> > platforms regardless of that.
>
> I had a very quick attempt on cygwin the other night, and it behaved
> differently at the 'ninja test' stage. It printed something like
> '[0/1] all tests' and then seemed to do nothing, except 'python3.9'
> was hovering up all cycles (well over 75% anyway) with no indication
> of any progress. This was nothing like the behaviour on Linux (which
> also looked a bit strange, but at least showed progress on each test
> as it ran).
>
> I ^C-ed it, since I didn't want to wait 6 hours before it (hopefully)
> finished running.
Interesting, that's something I didn't experience yet. I'll chime in
further down in this thread.
Patrick
