Re: [RFC PATCH v4 00/19] Modernize the build system

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

 




On 24/10/2024 13:39, Patrick Steinhardt wrote:
> Hi,
> 
> this is the fourth version of my patch series that modernizes our build
> system. It refactors various parts of it to make it possible to perform
> out-of-tree builds in theory and then wires up Meson.

As Promised, I have tested this version on Linux and Cygwin (not full test
on patches 1-18). When built on top of fd3785337b (The third batch) with
the two branches merged (as indicated below) Linux (build+test) and cygwin
(just build) work as expected.

> Changes compared to v3:
> 
>   - Various typo fixes.
> 
>   - Our Makefile now detects unsubstituted build options in the newly-
>     introduced "GIT-BUILD-OPTIONS.in" template.
> 
>   - I've wired up support for building and installing manpages. This was
>     the last important bit missing to get a fully functioning Git
>     installation. We generate the same set of manpages that our Makefile
>     would and also render a subset of the HTML pages we generate. Not
>     wired up are our technical docs, but doing those shouldn't be all
>     that involved.
> 
>     Documentation is not built by default, but can be enabled by passing
>     any combination of `-Ddocs=html,man`.

I haven't tried this (yet).

>   - I've dropped the target names for `custom_target()` invocations.
>     Those are auto-derived from the first output anyway, so they only
>     add unnecessary noise.
> 
>   - 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.

I couldn't try this patch because (at the time) the 'seen' branch
didn't build. :(

>     @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'.

As indicated above, this worked just fine.

Now that 'seen' builds again [92855bf61d ("Merge branch 'ps/build' into seen",
2024-10-27)], I tested meson on Linux and Cygwin (build and *full* test this
time).

On Linux, the result looks like:

  $ tail meson-logs/testlog.txt
  Summary of Failures:
  
   117/1035 t1017-cat-file-remote-object-info              FAIL            0.01s   exit status 2
  
  Ok:                 1034
  Expected Fail:      0   
  Fail:               1   
  Unexpected Pass:    0   
  Skipped:            0   
  Timeout:            0   
  $ 
  
It looks like a branch has been removed from 'seen'. :) (ie the t1017* test
file does not exist).

On cygwin, the result looks like:

  $ tail -11 meson-logs/testlog.txt
  Summary of Failures:
  
    23/1035 t-reftable-stack                               TIMEOUT        30.26s   killed by signal 15 SIGTERM
   114/1035 t1017-cat-file-remote-object-info              FAIL            0.13s   exit status 127
  
  Ok:                 1033
  Expected Fail:      0   
  Fail:               1   
  Unexpected Pass:    0   
  Skipped:            0   
  Timeout:            1   
  $ 

The t-reftable-stack unit test took just over 75s on the v2.27.0 test run.
I haven't looked into it yet, but plenty of other tests run for longer than
the 30s, so I don't know why that test seems to be different.

Also, it is worth noting that the test ran for 2hr50min. Usually I have to
wait 6hr approx. for 'make test' to finish because I don't like to use any
'-j' parameters (You can't do anything else on the machine while it is
cooking the cpu!). :)

Thanks!

ATB,
Ramsay Jones






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux