On 29 Apr 2015 03:51, "Ken Moffat" <zarniwhoop@...3141...> wrote:
- 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.
Configuration will always be slow on Windows, since starting a process takes several milliseconds.
On Linux though, all the macro processing in Autotools adds noticeable overhead.
== 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 ;)
We can always add stub makefiles or stub configure scripts if it helps users, so that you can do configure, make, make install as usual. From the developer perspective, Autotools is a giant pile of spaghetti and debugging a nontrivial problem is a total nightmare that requires you to know several obscure languages.
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.
You can set all the dirs via options such as --docdir if you import the module gnu_dirs, and CFLAGS etc. are picked up from the environment like in configure.
== 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.
It also allows you to use make replacements such as tup or ninja and has Visual Studio project generation, but essentially yes.
Regards, Krzysztof