On Jan 10, 2016 13:09, "Thorsten Schöning" <tschoen...@am-soft.de> wrote: > > Guten Tag Wiebesiek, Torsten, > am Sonntag, 10. Januar 2016 um 19:03 schrieben Sie: > > > I don't want to start a general discussion about which build system > > is best. Such thing does not exist. > > But some day we need to decide, e.g. if a complete rewrite for CMAKE > is preferable over staying with autoconf AND some folks need to do it > of course. ;-)
So this is a perennial topic on all the C projects. The answers on the other components that most log4cxx users must also build for their larger work vary from vanilla or gnu make to roll-their-own to autoconf to automake to scons to cmake. Getting 20 subcomponents built in this ecosystem can be painful. Autoconf is nice in that it is nearly entirely portable across unixes and build system tooling needs not be installed. Cmake is nice in that it is more portable, but requiring every build environment to install cmake is as horrible as requiring the entire autocruft toolchain (due to poor choices around AM_MAINTAINER_MODE default behavior, which sadly devolves to a religious war over the one right way to construct build tooling.) The APR project seems to be at a consensus that requiring cmake on systems that can't process autoconf ./configure script is not an unreasonable hardship. If the overly explicit win32 makefiles emitted by cmake can be massaged into a relocatable file path, those will likely be salvaged and shared too in the release packages so the project can dump 20 year old unsupported VS 6 project files. Cmake allows export to dozens of IDE build schemas, so it has that going for it, and expecting the developer (as opposed to a buildbot) to have cmake handy isn't that bad to enjoy a GUI dev experience. Plus the cmake schema can be tested by OSX and Linux participants, even if their natural expression would be to use the autoconf way - other windows solutions rely entirely on contribution and sharp eyes of windows project participants. So for the long haul, APR is pretty much resigned to the coexistence of more than one build tooling solution :). And it is looking like autoconf and cmake for the near term. > And as could be read in the releasing aspect: If we want votes for > releases, things need to build on voters systems. If there is guidance, even straight c/cpp code can constitute a release. But as a practical matter, a build schema is good, especially if you want the FreeBSD and Debian and Fedora and OSX experience to be anywhere close to similar. Giving them a starting point is valuable. Adding an extra set of build options can be good until it overwhelms the maintainers to keep it all in sync. Just some food for thought from a package maintainer. Cheers, Bill
