On 29 Apr 2015 05:35, "Bryce Harrington" <bryce@...961...> wrote:
>
> On Wed, Apr 29, 2015 at 02:51:15AM +0100, Ken Moffat wrote:
> > 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.
>
> True, cmake doesn't have as nice of a listing as automake.  You can at
> least get a list of the variables and their defaults via:
>
>   cmake -L
>
> Running that in Inkscape's root currently provides two or three dozen
> configurable settings.

Most of those settings would be autodetected based on automated tests, is that correct?

> Once you've run cmake, it produces a CMakeCache.txt file which has the
> latest detected parameters, along with textual descriptions of each
> item.
>
> > 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.
>
> Odd.  Well what I know is it's fairly easy to set up config options to
> exclude dependencies.  For instance here's a snippet from one of my
> packages, which lets users build without libcairo:
>
> # ----------------------------------------------------------------------
> # Command line options
> # ----------------------------------------------------------------------
> option(ENABLE_CAIRO "Build in cairo tests" ON)
> ...
>
> # ----------------------------------------------------------------------
> # Dependencies
> # ----------------------------------------------------------------------
> set(USE_CAIRO 0)

This syntax is worse than COBOL if you ask me :/

Also fun fact: some things in CMake are case sensitive and some are not.

> if (ENABLE_CAIRO)
>   find_package(Cairo REQUIRED)
>   message("Using cairo libraries at ${CAIRO_LIBRARIES}")
>   list(APPEND CASKBENCH_INCS_SYS ${CAIRO_INCLUDE_DIRS})
>   list(APPEND CASKBENCH_LIBS ${CAIRO_LIBRARIES})

This is ten times worse than COBOL. Even Bash has better syntax for appending to arrays / lists.

>   check_include_files(cairo/cairo-gl.h HAVE_CAIRO_GL_H)
>   set(USE_CAIRO 1)
> endif (ENABLE_CAIRO)

And this XML-like closing of ifs, without any of the benefits of XML... AFAIK it's been recently made optional, but still...

If the majority thinks that CMake is the best option, I won't oppose it, but I won't waste my time adding any features to the build system either.

>
> The user can then force Cairo off via:
>
>    $ cmake . -DENABLE_CAIRO=OFF
>
> Personally I find this syntax a lot easier to understand (and debug)
> than autoconf.

Waf code for comparison (from memory, may slightly differ)

def options(ctx):
    ctx.add_option('--enable-cairo', action='store_true', msg='Build in Cairo tests')
    ctx.add_option('--disable-cairo', action='store_true', msg='Do not use Cairo even if present on the system')
...
def configure(ctx):
    if not ctx.options.disable_cairo:
        ctx.check_package('CAIRO', '1.12', mandatory=ctx.options.enable_cairo)

Then:
./waf configure --enable-cairo
Or
./waf configure --disable-cairo

Options are handled by standard Python option parsing modules, so learning how to add them in Waf allows you to use this in your standalone Python scripts; no such advantage exists for CMake.

Since this is Python, common patterns such as adding both an enable and a disable option for a package can be easily put in functions, which reduces clutter.

> > 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.
>
> Sure, try running cmake -L in your current inkscape checkout, and then
> read from the top of the generated CMakeCache.txt to get a listing of
> available options, their current values, and descriptive text about what
> they do.  Tell me if you think that will at least address the basic
> needs?
>
> We should document the above in our README, and then just make sure all
> the option()'s have good descriptions, and I *think* we should be golden
> here.
>
> Thanks for the feedback!
> Bryce
>
> > > 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:
> > >
> > > 1. 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.
> >
> > > 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.
> >
> > > 4. 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
> > --
> > Nanny Ogg usually went to bed early. After all, she was an old lady.
> > Sometimes she went to bed as early as 6 a.m.
> >
> > ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Inkscape-devel mailing list
> > Inkscape-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel