[Pixman] [PATCH] Add CMake build rules

[Pekka Paalanen]

On Sun, 22 May 2016 01:54:36 +0000
whitequark <whitequark at whitequark.org> wrote:

> CMake is a popular build system for C/C++ projects. One key property
> it has is that a library using CMake can be "drop in" vendored,
> that is, placed in the build tree of another project using CMake
> and immediately used as if it was a part of that project.
> 
> There is no intermediate configuration step or build directories,
> and it is enough to set up a (perhaps cross-)toolchain once for
> the toplevel project. This results in a massive usability improvement
> for the case where a project links many static libraries, such as
> when deploying to Windows or Android, and especially when there is
> a combinatorial explosion of targets and target options, such as
> on Android, where it is necessary to produce x86, ARM and MIPS builds
> in order to target the majority of devices.
> 
> For this reason, many projects (including, for example, zlib and
> Freetype) opt to provide CMake build rules alongside autoconf ones.
> 
> These build rules closely follow the existing autoconf-based rules,
> to the degree that any change in autoconf files should trivially
> translate to changes in CMakeLists.txt, reducing maintainer workload.
> In particular, it uses the same code to test for target-specific
> compiler features.
> 
> There is no SunOS support, because SunOS is responsible for most
> corner cases in the autoconf build rules and it is unlikely that
> anyone is interested in using CMake for SunOS builds.
> 
> The CMake build rules were tested on:
>    * x86_64-linux-gnu;
>    * arm-linux-gnueabi;
>    * mips-linux-gnu;
>    * powerpc-linux-gnu.
> On all targets, the target features were manually verified to pass
> when they ought to, and the target-specific implementations were
> manually verified to be linked in.
> 
> On x86_64-linux-gnu, all tests were verified to pass.
> On other targets, all tests were verified to link correctly.
> 
> [actual patch included as attachment]

Hi,

please always put patches as inline.

This sounds like a very very bad idea to me, and I think the
execution is even worse.

If Mesa has tought us anything, it is that a project with multiple
build systems is much harder to maintain. Mesa struggles with it at
times, even when it has many active *paid* developers using both (I
think it is down to two now.. no, three: autotools, scons and
Android) build systems.

That said, Mesa actually tried to make that maintenance manageable,
which I do not really see from your patch.

Assuming people were happy adding a new build system, which I very
much doubt, let's look at your patch.

 8 files changed, 740 insertions(+)

No deletions.

You use regexes to fetch the version numbers from configure.ac,
right?

That seems to be the only thing you use from the current build
system. IOW, you are duplicating:
- all source file lists
- all build rules (built binaries)
- all hand-written code checking for compiler features
- config.h template

I believe that all that duplication will be a huge pain for
upstream. It is already labourious to ask people to test on various
platforms, and this will double the required effort.

Adding the CMake files to Pixman may be a one-shot effort for you,
but then the upstream maintainers and developers (who are very few
and already burdened) are stuck with it, now trying to learn
how CMake works, and spending hours verifying the build systems
are consistent (or letting CMake just rot and refuse all bug
reports from CMake-built binaries, in which case why even bother
merging in the first place).

For what benefit? So that people who set up cross-build toolchains
and projects as their job have one less component to make that
setup for?

If you could promise, as a company, to assign a developer whose job
will be to maintain this in Pixman, then just maybe it could make
sense, but so far I think this patch would be a turn for the worse
for Pixman.

Or would you perhaps offer a CI system automatically building with
both autotools and CMake and verifying they work the same on all
the platforms where you care about CMake?

Upstream should either fully endorse CMake as a new official build
system for Pixman, in which case you would try to share as much
configuration with autotools as possible, or, just reject it.

I wonder what others think?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/pixman/attachments/20160522/ae6806a3/attachment.sig>