On 29 Apr 2015 03:51, "Ken Moffat" <zarniwhoop@...3141...> wrote:
>
> > 2. 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