On Sun, 22 May 2016 01:54:36 +0000 whitequark <whitequ...@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
pgpMj8PWfKp8v.pgp
Description: OpenPGP digital signature
_______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pixman