On Tue, Apr 28, 2015 at 11:00:44PM +0100, Alex Valavanis wrote:
Summary: We propose making CMake our recommended build system for Inkscape 0.92 onwards and removing our Autotools support in 0.93. We will also consider moving to Waf in future if it seems beneficial. Any comments are warmly welcomed, particularly from Windows and OS X users.
I'm not a windows or osx user, so my default position is that autofoo is reasonably understandable (for a builder! e.g. you will normally get help from ./configure --help, and sometimes it is even accurate, e.g. for determining if you wish, or do not wish, to install static libs). Obviously, specific configure scripts vary about how obvious, or accurate, things are. And those which also build on osx or mingw (that's inkscape, I suppose) can be harder to analyze when looking at possible dependencies in new versions.
Modern versions of cmake seem to be much better than those from a few years ago (fewer weird dependencies if you want to use system versions of libraries, rather than (static versions of) those which might have been shipped in cmake's source). But documentation for builders (i.e. what options I can change, which extra dependencies exist which I might want to enable) seems to generally be absent. Best case, a new version of a cmake package will detect that a library is not present when cmake runs, and either cmake fails or it puts out a suggestion. I don't recall ever seeing a cmake package offer an option to NOT include a particular dependency (fairly common in configure scripts), but I'm not sure that is relevant to inkscape.
Worst case, the build fails during 'make' - the main offenders are those kde4 packages which need a static qt lib and don't think to check if it can be found.
So, I hope that there will be easily-accessible documentation on options (if there are any!) when inkscape moves to cmake.
Hi All,
At the Hackfest, we have discussed some options for improving our build systems and would like to invite your comments.
== Present situation == At the moment, we provide both Autotools (autoconf, automake etc) and CMake, but our main focus has been on Autotools. This is causing a significant maintenance challenge for the following reasons:
- The syntax of the Autotools configuration files is rather complex
and uses a mixture of the M4 Macro processing language, and bash scripting which is hard to understand/edit/debug
Actually, it _should_ be traditional sh without bash extensions. But there are many offenders, particularly from gnu.
- Numerous configuration files are needed to support both build
systems. This adds a significant maintenance burden whenever e.g., files are added/removed or package version numbers change 3. The Autotools configuration is pretty slow, and parallelisation overheads are quite high
This I do not understand. You run ./configure, or ./autogen.sh, or whatever, it takes a number of seconds and creates one or more Makefiles. You then run make -jN and the parallelisation overhead is determined by which dependencies exist.
- The CMake builds tend to be fairly neglected, and are not very
actively maintained.
Whereas with cmake on linux, cmake runs for a number of seconds and creates one or more Makefiles. And after that, make -jn should be identical. In fact, if the Makefiles are NOT identical, one of the processes would seem to be incorrect.
Also, if the cmake builds are neglected, I hope you have people willing to step up to the task.
== Proposal == We would like to focus on a single build system. CMake is more widely understood than Autotools and it should be easier for more people to manage our conditional build configuration.
From a linux perspective, the only things less-well understood than
autotools are the alternatives such as cmake ;)
As a first step, we could focus on improving the CMake build and recommending this as our default option for the next Inkscape release (0.92). We could then remove our Autotools build system entirely from Inkscape 0.93 onwards.
Another potential option for future releases is the Waf system, which offers very good wildcard handling and potentially even simpler build configuration. However, I think it would make sense to stabilise our existing CMake build before we start moving to anything new
Waf, outside of Python modules, is not commonly encountered. For Python, I'm sure it is easy, and fairly quick to understand in any package which uses it. For other projects where you might want to specify e.g. prefix, libdir, docdir or even CFLAGS or CXXFLAGS it seems much less obvious.
== Portability == We need to determine whether the CMake builds work well on OS X and Windows systems. Any comments from users of those systems would be greatly appreciated.
I had assumed it was users from Windows who were keen to use cmake - for linux, and I assume for osx/darwin/bsd, it is just a replacement for ./configure.
Moving to cmake has been mentioned for some time, and cmake is now required on _my_ linux desktops (for harfbuzz), so it doesn't come as a surprise to hear this. Speaking as a "legacy sysvinit, minimal unnecessary additions" guy, I'm sure it won't cause any real problems. Best Wishes for the change.
ĸen