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.
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) 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}) check_include_files(cairo/cairo-gl.h HAVE_CAIRO_GL_H) set(USE_CAIRO 1) endif (ENABLE_CAIRO)
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.
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:
- 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
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