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. ----
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 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 4. The CMake builds tend to be fairly neglected, and are not very actively maintained.
== 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.
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
== 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.
Best wishes,
Alex
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
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
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:
- 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
------------------------------------------------------------------------------
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
On Wed, Apr 29, 2015 at 03:35:36AM -0400, Krzysztof Kosiński wrote:
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?
Yes. Presumably they're all autodetected. 99% of the time one should not need to bother with any of them.
Bryce
On Tue, Apr 28, 2015 at 08:35:00PM -0700, Bryce Harrington 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.
Once you've run cmake, it produces a CMakeCache.txt file which has the latest detected parameters, along with textual descriptions of each item.
Tried it first in 0.91, but of course that doesn't have CMakeLists.txt except in src/2geom. Built bazaar, downloaded the current version.
Yes, cmake -L appears to know what it is doing (noted some things I have not installed, found current cairo and poppler). But everything else where I have invoked cmake from a build/ directory has dumped the Makefile into the build directory. Inkscape put it in the top level directory. Building seemed to be going well, until
[ 65%] Building CXX object src/CMakeFiles/inkscape.dir/ui/dialog/text-edit.cpp.o /scratch/ken/bazaar/inkscape/src/ui/dialog/text-edit.cpp:29:32: fatal error: gtkspell/gtkspell.h: No such file or directory compilation terminated.
And when I look back at the cmake output it says: -- checking for module 'gtkspell-2.0' -- package 'gtkspell-2.0' not found
but apparently finished ok, reporting -- Configuring done -- Generating done -- Build files have been written to: /scratch/ken/bazaar/inkscape
In CMakeCache.txt is has things like _GTKSPELL_VERSION:INTERNAL= _GTKSPELL_gtkspell-2.0_INCLUDEDIR:INTERNAL= _GTKSPELL_gtkspell-2.0_LIBDIR:INTERNAL= _GTKSPELL_gtkspell-2.0_PREFIX:INTERNAL= _GTKSPELL_gtkspell-2.0_VERSION:INTERNAL=
but there is no internal copy.
Looking at configure.ac there is still an option for gtk3, but nothing like that in the 'cmake -L' output and CMakeLists.txt only mentions GTK2 stuff : I did a DESTDIR gtk3 build of 0.91 earlier this evening (testing everything with gcc-5).
I'll go back to playing with other things until you get nearer to a release ;)
ĸen
On Sat, May 02, 2015 at 11:39:34PM +0100, Ken Moffat wrote:
On Tue, Apr 28, 2015 at 08:35:00PM -0700, Bryce Harrington 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.
Once you've run cmake, it produces a CMakeCache.txt file which has the latest detected parameters, along with textual descriptions of each item.
Tried it first in 0.91, but of course that doesn't have CMakeLists.txt except in src/2geom. Built bazaar, downloaded the current version.
Yes, cmake -L appears to know what it is doing (noted some things I have not installed, found current cairo and poppler). But everything else where I have invoked cmake from a build/ directory has dumped the Makefile into the build directory. Inkscape put it in the top level directory.
Probably a bug in our cmake scripts. Please file a bug report and tag it 'build cmake'. (And attach a patch if you have an idea for a fix.)
Building seemed to be going well, until
[ 65%] Building CXX object src/CMakeFiles/inkscape.dir/ui/dialog/text-edit.cpp.o /scratch/ken/bazaar/inkscape/src/ui/dialog/text-edit.cpp:29:32: fatal error: gtkspell/gtkspell.h: No such file or directory compilation terminated.
And when I look back at the cmake output it says: -- checking for module 'gtkspell-2.0' -- package 'gtkspell-2.0' not found
What it's doing at that point is shelling out to pkg-config to see if gtkspell is installed.
pkg-config --cflags --libs gtkspell-2.0
Run ^ that on your commandline and see what it says. If you don't have it installed, install it. :-)
but apparently finished ok, reporting -- Configuring done -- Generating done -- Build files have been written to: /scratch/ken/bazaar/inkscape
In CMakeCache.txt is has things like _GTKSPELL_VERSION:INTERNAL= _GTKSPELL_gtkspell-2.0_INCLUDEDIR:INTERNAL= _GTKSPELL_gtkspell-2.0_LIBDIR:INTERNAL= _GTKSPELL_gtkspell-2.0_PREFIX:INTERNAL= _GTKSPELL_gtkspell-2.0_VERSION:INTERNAL=
but there is no internal copy.
Since the pkg-config call failed earlier, these won't be defined.
The FindGtkSpell.cmake module is pretty simple; it just calls pkg-config. But if you *do* have gtkspell installed, then you may want to look there for debugging the problem.
Looking at configure.ac there is still an option for gtk3, but nothing like that in the 'cmake -L' output and CMakeLists.txt only mentions GTK2 stuff : I did a DESTDIR gtk3 build of 0.91 earlier this evening (testing everything with gcc-5).
The gtk3 stuff for automake is still very much a work in progress. I believe Alex is mostly working on it on a branch. One day we'll bring all that in-tree and convert Inkscape over, but not this release. Gtk3 probably has nothing to do with your issue though.
I'll go back to playing with other things until you get nearer to a release ;)
Actually, it would be helpful if you can keep banging on this, because getting it working on *your* machine does in fact bring us closer to the release. :-)
Bryce
On Sat, May 02, 2015 at 06:34:57PM -0700, Bryce Harrington wrote:
On Sat, May 02, 2015 at 11:39:34PM +0100, Ken Moffat wrote:
On Tue, Apr 28, 2015 at 08:35:00PM -0700, Bryce Harrington 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.
Once you've run cmake, it produces a CMakeCache.txt file which has the latest detected parameters, along with textual descriptions of each item.
Tried it first in 0.91, but of course that doesn't have CMakeLists.txt except in src/2geom. Built bazaar, downloaded the current version.
Yes, cmake -L appears to know what it is doing (noted some things I have not installed, found current cairo and poppler). But everything else where I have invoked cmake from a build/ directory has dumped the Makefile into the build directory. Inkscape put it in the top level directory.
Probably a bug in our cmake scripts. Please file a bug report and tag it 'build cmake'. (And attach a patch if you have an idea for a fix.)
I'll take another look later. As you can tell, I don't have much understanding of cmake but I'll look at a couple of other packages (I lied when I said I build cmake for harfbuzz, it's actually for graphite2) including some kde stuff.
Building seemed to be going well, until
[ 65%] Building CXX object src/CMakeFiles/inkscape.dir/ui/dialog/text-edit.cpp.o /scratch/ken/bazaar/inkscape/src/ui/dialog/text-edit.cpp:29:32: fatal error: gtkspell/gtkspell.h: No such file or directory compilation terminated.
And when I look back at the cmake output it says: -- checking for module 'gtkspell-2.0' -- package 'gtkspell-2.0' not found
What it's doing at that point is shelling out to pkg-config to see if gtkspell is installed.
pkg-config --cflags --libs gtkspell-2.0
Run ^ that on your commandline and see what it says. If you don't have it installed, install it. :-)
I know I don't have it installed. If it is now required, I assumed cmake would tell me.
but apparently finished ok, reporting -- Configuring done -- Generating done -- Build files have been written to: /scratch/ken/bazaar/inkscape
In CMakeCache.txt is has things like _GTKSPELL_VERSION:INTERNAL= _GTKSPELL_gtkspell-2.0_INCLUDEDIR:INTERNAL= _GTKSPELL_gtkspell-2.0_LIBDIR:INTERNAL= _GTKSPELL_gtkspell-2.0_PREFIX:INTERNAL= _GTKSPELL_gtkspell-2.0_VERSION:INTERNAL=
but there is no internal copy.
Since the pkg-config call failed earlier, these won't be defined.
The FindGtkSpell.cmake module is pretty simple; it just calls pkg-config. But if you *do* have gtkspell installed, then you may want to look there for debugging the problem.
Looking at configure.ac there is still an option for gtk3, but nothing like that in the 'cmake -L' output and CMakeLists.txt only mentions GTK2 stuff : I did a DESTDIR gtk3 build of 0.91 earlier this evening (testing everything with gcc-5).
The gtk3 stuff for automake is still very much a work in progress. I believe Alex is mostly working on it on a branch. One day we'll bring all that in-tree and convert Inkscape over, but not this release. Gtk3 probably has nothing to do with your issue though.
I'll go back to playing with other things until you get nearer to a release ;)
Actually, it would be helpful if you can keep banging on this, because getting it working on *your* machine does in fact bring us closer to the release. :-)
Bryce
At the moment, it is late (3 a.m.). The system will eventually be thrown away, but it needs to do a few other things first. For gtkspell I'll try to take a look, but no promises.
ĸen
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
On 2015-04-29 24:00 (+0200), Alex Valavanis wrote:
== 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.
Summary (Mac OS X 10.7.5): ========================== - configuration failure - build failure (with current poppler) - link failure (compilation itself succeeds without poppler) It is unknown at this point what changes will be required for actual packaging (configuring as osxapp, adding whatever tasks for packaging were handled via autotools to Cmake config files, updating build scripts)
Question: ========= Before I go into details (you can skip anything below this paragraph if not interested): does anyone know a GTK+ project of the size of Inkscape, with a similar range of supported platforms, which does use cmake, and does have a current port in MacPorts?
Local setup: ============ MacPorts [1] uses '/opt/local' as default prefix unless installed from source and configured with a different prefix.
In order to be able to build inkscape with both available GTK+ backends on OS X (X11, Quartz), it is required to install two separate MacPorts trees into different (i.e. custom) prefixes (they do not share any files, nor know about each other; one has to take care to never mix the environments in the current shell). Inkscape - using the existing, working build system - then can be configured at build time with either of the two prefixes for the dependencies.
The ultimate goal of this (time-consuming) exercise is to be able to investigate, test&compare and hopefully one day provide what so many Mac users expect from the project (and nothing else): Inkscape for OS X without X11 dependency and with better OS integration.
Current autotools handle such setups ok - dependencies are retrieved via pkg-config in $PATH, nothing outside is pulled in unintentionally or uncontrollably. Inkscape's configure.ac and Makefiles help with that (for example: they don't pull in '-lX11' unnecessarily if not using X11 [2]).
Testing Cmake with trunk (r14067): ================================== Build setup (Gtk+/Quartz 2.24.27, no X11 dependencies): ## Prefix for required packages: $ echo $MP_QUARTZ_PREFIX /Volumes/magenta/mp-trunk/quartz $ echo $PATH /Volumes/magenta/mp-trunk/quartz/bin:/Volumes/magenta/mp-trunk/quartz/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/su_v/.local/bin ## Cmake is installed in $MP_QUARTZ_PREFIX $ type -p cmake /Volumes/magenta/mp-trunk/quartz/bin/cmake $ cmake --version cmake version 3.2.1 ## which pkg-config is used? $ type -p pkg-config /Volumes/magenta/mp-trunk/quartz/bin/pkg-config
## new branch in local shared repo: $ bzr branch lp:inkscape inkscape-cmake ## we want to build out-of-source $ mkdir cmake-build $ cd cmake-build ## run plain cmake $ cmake ../inkscape-cmake ## or run cmake with Ninja ## cmake ../inkscape-camke -G Ninja
Results: (default Unix-Makefiles or Ninja did not make a difference) ======== 1) complete failure to find anything related to gtk/gtkmm and deps:
GTK2_CAIROMMCONFIG_INCLUDE_DIR:PATH=GTK2_CAIROMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GDKCONFIG_INCLUDE_DIR:PATH=GTK2_GDKCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GDKMMCONFIG_INCLUDE_DIR:PATH=GTK2_GDKMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GIOMMCONFIG_INCLUDE_DIR:PATH=GTK2_GIOMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GLIBCONFIG_INCLUDE_DIR:PATH=GTK2_GLIBCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GLIBMMCONFIG_INCLUDE_DIR:PATH=GTK2_GLIBMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GTKMMCONFIG_INCLUDE_DIR:PATH=GTK2_GTKMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_PANGOMMCONFIG_INCLUDE_DIR:PATH=GTK2_PANGOMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_SIGC++CONFIG_INCLUDE_DIR:PATH=GTK2_SIGC++CONFIG_INCLUDE_DIR-NOTFOUND
Even after manually setting these variables correctly (why does cmake not use pkg-config to find out about those packages?), there were still two left which I didn't find in ccmake (even in advanced mode), and thus had to to be set directly in CMakeCache.txt:
//Path to a library. GTK2_GDK_LIBRARY:FILEPATH=GTK2_GDK_LIBRARY-NOTFOUND
and
//Path to a library. GTK2_GTK_LIBRARY:FILEPATH=GTK2_GTK_LIBRARY-NOTFOUND
2) failure to support poppler >= 0.29: The latest inkscape build breakage due to a new poppler release (0.29) isn't handled by current CMake configuration (latest poppler version installed locally: 0.32)
3) random and opportunistic detection of dependencies: On closer inspection of CMakeCache.txt, it seems that the detection of required packages is based on some (to me inexplicable) mixture of searching in hard-coded presumed "default" paths, with occasional mixed-in results which can only have been retrieved via (or preferred from results returned by) pkg-config.
Some required dependencies are thus referenced from different locations (paths), without any apparent logic. This also includes opportunistically pulling in libraries installed by XQuartz (the OS X port of X.org), even for a build setup which neither depends on X11, nor uses it.
Affects for example:
- freetype:
//Path to a file. FREETYPE_INCLUDE_DIR_freetype2:PATH=/usr/X11R6/include/freetype2
//Path to a file. FREETYPE_INCLUDE_DIR_ft2build:PATH=/Volumes/magenta/mp-trunk/quartz/include/freetype2
//Path to a library. FREETYPE_LIBRARY:FILEPATH=/Volumes/magenta/mp-trunk/quartz/lib/libfreetype.dylib
- libxml2:
//Path to a file. LIBXML2_INCLUDE_DIR:PATH=/Volumes/magenta/mp-trunk/quartz/include/libxml2
//Path to a library. LIBXML2_LIBRARIES:FILEPATH=/usr/lib/libxml2.dylib
//Path to a program. LIBXML2_XMLLINT_EXECUTABLE:FILEPATH=/Volumes/magenta/mp-trunk/quartz/bin/xmllint
- libxslt:
//Path to a library. LIBXSLT_EXSLT_LIBRARY:FILEPATH=/usr/lib/libexslt.dylib
//Path to a file. LIBXSLT_INCLUDE_DIR:PATH=/usr/include
//Path to a library. LIBXSLT_LIBRARIES:FILEPATH=/usr/lib/libxslt.dylib
//Path to a program. LIBXSLT_XSLTPROC_EXECUTABLE:FILEPATH=/Volumes/magenta/mp-trunk/quartz/bin/xsltproc
For all of the above examples, the preferred (and in my view correct) version would be the one which is installed in the local prefix (i.e. as found by pkg-config in $PATH).
4) linker failure: The initial attempt (plain cmake and make), as well as a second attempt with cmake+ninja failed in the end with the same linker error after compilation itself was successful (poppler had been disabled in ccmake since the installed version is not supported with cmake-based builds):
ld: library not found for -lpangocairo-1.0 clang: error: linker command failed with exit code 1 (use -v to see invocation)
I haven't further investigated yet (nor any idea) where this error originates from - linking just works as expected with autotools-based builds (with either backend).
5) There are likely plenty of details not mentioned above - I'm not familiar with cmake myself, and have yet to learn even the most basic aspects of this build system.
Comments: ========= The major issue I encountered in this initial attempt (apart from the linker failure) is that cmake-based builds seem to prefer to look in hard-coded paths for packages. While it is true that my local test build setup does not use "default" locations (for a reason), I don't think that the build system overall should pose such a limitation to the user.
Ideally, I'd like to learn from cmake-experts how to either prepend search paths (mostly for GTK2-related packages) or change default prefixes via command line when calling cmake, or - if this is not supported by cmake's default Modules or the custom copies which are shipped with inkscape - how to best modify them in such a way that the required changes can be integrated in local build scripts (manually tweaking the config via ccmake or CMakeCache.txt each time is not an option).
hth, V
Minor update:
On 2015-04-29 08:05 (+0200), su_v wrote:
The major issue I encountered in this initial attempt (apart from the linker failure) is that cmake-based builds seem to prefer to look in hard-coded paths for packages. While it is true that my local test build setup does not use "default" locations (for a reason), I don't think that the build system overall should pose such a limitation to the user.
Ideally, I'd like to learn from cmake-experts how to either prepend search paths (mostly for GTK2-related packages) or change default prefixes via command line when calling cmake, or - if this is not supported by cmake's default Modules or the custom copies which are shipped with inkscape - how to best modify them in such a way that the required changes can be integrated in local build scripts (manually tweaking the config via ccmake or CMakeCache.txt each time is not an option).
houz helped me solving the problem how to find GTK2 installed into custom prefix: 1) works: setting the env variable $GTKMM_BASEPATH to the custom MacPorts prefix (in the shell where cmake is run) 2) the module FindGTK2.cmake distributed with Inkscape is outdated (it does not support the Quartz backend of GTK2); this has been fixed upstream in cmake. Removing the outdated copy in Inkscape's CMakeScripts/Modules forces cmake to use the newer version it installed itself (works).
Now on to the remaining issues (as in: fix wrongly detected include dirs and libs from unrelated locations, still fails to link, support for GTK+/Quartz hasn't been added to Inkscape's cmake files yet, etc.)
Cheers, V
Minor update 2:
On 2015-04-29 17:46 (+0200), su_v wrote:
(...) on to the remaining issues (as in: fix wrongly detected include dirs and libs from unrelated locations,
Solved (for now): To prefer packages installed in custom prefix, set (and export) the environment variable $CMAKE_PREFIX_PATH to the custom prefix (it prevents e.g. linking against older libxml2 found in /usr/lib while the dependencies use the up-to-date version installed in custom prefix).
See also: http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_PREFIX_PATH.html
still fails to link, support for GTK+/Quartz hasn't been added to Inkscape's cmake files yet, etc.)
Still open.
Cheers, V
Minor update 3 (the last one in this thread ;-) ):
On 2015-04-29 19:58 (+0200), su_v wrote:
still fails to link, support for GTK+/Quartz hasn't been added to Inkscape's cmake files yet, etc.)
Still open.
Summary (cmake build on Mac OS X 10.7.5): ========================================= Linker errors have been identified, and worked around by - prepending $CMAKE_PREFIX_PATH/lib as library search path - adding more (hard-coded) libs (temporary, needs fixing)
Notes: ====== Known issues - general: - poppler >= 0.29 not supported (breaks build) - newer librevenge-based input formats (libwpg, libcdr, libvisio) not supported (see related sections in configure.ac) - CMake's module for ImageMagick seems outdated and misses defines [1] - ...
Known issues - OS X: - failing tests in ConfigChecks.cmake (e.g. to detect existing gtk features) - missing includes/libs for the predefined tests? - no checks for gtk backend (don't pull in X11 unless used, configure for gtk-mac-integration (future)) - workarounds for linker failures seem too simplistic compared to the tests done by autotools-based build system (--> simply adding '-liconv -lintl' is likely to break on other systems (?)) - Cmake's FindFreetype.cmake module still lists path name of older freetype versions first [2]. This causes cmake to opportunistically detect an older version of freetype which happens to be installed on the local system (Lion's original X11 in /usr/X11R6 --> /usr/X11), completely outside any configured prefixes. Deleting the (incorrect) name in a local copy of the module works around this issue. - ... (to be continued)
Changes (WIP): ============== See diff used for local cmake build, currently maintained as gist [3]
References: =========== [1] see also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776832 [2] https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake#L76 [3] https://gist.github.com/su-v/c15cffe3b73c092ef397#file-02-changes-diff
Bryce,
Thanks for patching the CMake build files. I'm currently running a test on Ubuntu Trusty. One thing I note (without full investigation yet!) is that the build seems less strict in terms of deprecated symbols etc. We also still need to configure Gtk+ 3 experimental builds.
Best wishes,
Alex
On 30 April 2015 at 15:18, su_v <suv-sf@...58...> wrote:
Minor update 3 (the last one in this thread ;-) ):
On 2015-04-29 19:58 (+0200), su_v wrote:
still fails to link, support for GTK+/Quartz hasn't been added to Inkscape's cmake files yet, etc.)
Still open.
Summary (cmake build on Mac OS X 10.7.5):
Linker errors have been identified, and worked around by
- prepending $CMAKE_PREFIX_PATH/lib as library search path
- adding more (hard-coded) libs (temporary, needs fixing)
Notes:
Known issues - general:
- poppler >= 0.29 not supported (breaks build)
- newer librevenge-based input formats (libwpg, libcdr, libvisio) not supported (see related sections in configure.ac)
- CMake's module for ImageMagick seems outdated and misses defines [1]
- ...
Known issues - OS X:
- failing tests in ConfigChecks.cmake (e.g. to detect existing gtk features) - missing includes/libs for the predefined tests?
- no checks for gtk backend (don't pull in X11 unless used, configure for gtk-mac-integration (future))
- workarounds for linker failures seem too simplistic compared to the tests done by autotools-based build system (--> simply adding '-liconv -lintl' is likely to break on other systems (?))
- Cmake's FindFreetype.cmake module still lists path name of older freetype versions first [2]. This causes cmake to opportunistically detect an older version of freetype which happens to be installed on the local system (Lion's original X11 in /usr/X11R6 --> /usr/X11), completely outside any configured prefixes. Deleting the (incorrect) name in a local copy of the module works around this issue.
- ... (to be continued)
Changes (WIP):
See diff used for local cmake build, currently maintained as gist [3]
References:
[1] see also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776832 [2] https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake#L76 [3] https://gist.github.com/su-v/c15cffe3b73c092ef397#file-02-changes-diff
On Thu, Apr 30, 2015 at 04:18:40PM +0200, su_v wrote:
Minor update 3 (the last one in this thread ;-) ):
On 2015-04-29 19:58 (+0200), su_v wrote:
still fails to link, support for GTK+/Quartz hasn't been added to Inkscape's cmake files yet, etc.)
Still open.
Hi su_v, thanks for the summary, and congrats on getting a binary built, I'm still working on that.
Summary (cmake build on Mac OS X 10.7.5):
Linker errors have been identified, and worked around by
- prepending $CMAKE_PREFIX_PATH/lib as library search path
- adding more (hard-coded) libs (temporary, needs fixing)
Notes:
Known issues - general:
- poppler >= 0.29 not supported (breaks build)
- newer librevenge-based input formats (libwpg, libcdr, libvisio) not supported (see related sections in configure.ac)
- CMake's module for ImageMagick seems outdated and misses defines [1]
- ...
Can you make sure we have a bug or bugs filed on these issues, assuming you aren't planning on just tackling them directly? What do you think about using a new tag in the bug tracker for flagging cmake-specific build system issues? (Or maybe we could reuse the existing build system tag(s) and just filter by date?)
Known issues - OS X:
- failing tests in ConfigChecks.cmake (e.g. to detect existing gtk features) - missing includes/libs for the predefined tests?
- no checks for gtk backend (don't pull in X11 unless used, configure for gtk-mac-integration (future))
- workarounds for linker failures seem too simplistic compared to the tests done by autotools-based build system (--> simply adding '-liconv -lintl' is likely to break on other systems (?))
- Cmake's FindFreetype.cmake module still lists path name of older freetype versions first [2]. This causes cmake to opportunistically detect an older version of freetype which happens to be installed on the local system (Lion's original X11 in /usr/X11R6 --> /usr/X11), completely outside any configured prefixes. Deleting the (incorrect) name in a local copy of the module works around this issue.
- ... (to be continued)
Will you need a separate set of rules for X11-based builds, and for native builds?
Changes (WIP):
See diff used for local cmake build, currently maintained as gist [3]
Those changes all look good to me, please go ahead and land them. And don't be too shy about checking in more changes; we have a ways to go before these scripts are production ready.
Bryce
References:
[1] see also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776832 [2] https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake#L76 [3] https://gist.github.com/su-v/c15cffe3b73c092ef397#file-02-changes-diff
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
On 2015-04-30 18:07 (+0200), Bryce Harrington wrote:
On Thu, Apr 30, 2015 at 04:18:40PM +0200, su_v wrote:
Minor update 3 (the last one in this thread ;-) ):
(...)
Known issues - general:
- poppler >= 0.29 not supported (breaks build)
- newer librevenge-based input formats (libwpg, libcdr, libvisio) not supported (see related sections in configure.ac)
- CMake's module for ImageMagick seems outdated and misses defines [1]
- ...
Can you make sure we have a bug or bugs filed on these issues, assuming you aren't planning on just tackling them directly? What do you think about using a new tag in the bug tracker for flagging cmake-specific build system issues? (Or maybe we could reuse the existing build system tag(s) and just filter by date?)
In the past, we tagged cmake-related reports with two tags: 'build' (official tag), and 'cmake' (now added to the official list too). Is this sufficient?
I haven't filed reports yet for the listed issues, but will do so next week (if not yet covered by an existing report or solved).
Known issues - OS X:
- failing tests in ConfigChecks.cmake (e.g. to detect existing gtk features) - missing includes/libs for the predefined tests?
- no checks for gtk backend (don't pull in X11 unless used, configure for gtk-mac-integration (future))
- workarounds for linker failures seem too simplistic compared to the tests done by autotools-based build system (--> simply adding '-liconv -lintl' is likely to break on other systems (?))
- Cmake's FindFreetype.cmake module still lists path name of older freetype versions first [2]. This causes cmake to opportunistically detect an older version of freetype which happens to be installed on the local system (Lion's original X11 in /usr/X11R6 --> /usr/X11), completely outside any configured prefixes. Deleting the (incorrect) name in a local copy of the module works around this issue.
- ... (to be continued)
Will you need a separate set of rules for X11-based builds, and for native builds?
Both, but they overlap (for the most parts). For basic builds (without considering packaging as osxapp), we certainly need features to 1) avoid including/linking libraries not required by the current backend (only link X11 with X11 backend) 2) find required modules which are (or will be) specific to the backend (gtk-mac-integration for OS integration features with Quartz backend) I haven't looked into or tested packaging-specific issues yet (for example the '--enable-osxapp' configure option from autotools).
Changes (WIP):
See diff used for local cmake build, currently maintained as gist [3]
Those changes all look good to me, please go ahead and land them. And don't be too shy about checking in more changes; we have a ways to go before these scripts are production ready.
The gist has been updated with a few more changes - if there are no objections, I will commit them later today.
References:
[1] see also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776832 [2] https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake#L76 [3] https://gist.github.com/su-v/c15cffe3b73c092ef397#file-02-changes-diff
On Thu, Apr 30, 2015 at 08:55:31PM +0200, su_v wrote:
On 2015-04-30 18:07 (+0200), Bryce Harrington wrote:
On Thu, Apr 30, 2015 at 04:18:40PM +0200, su_v wrote:
Minor update 3 (the last one in this thread ;-) ):
(...)
Known issues - general:
- poppler >= 0.29 not supported (breaks build)
- newer librevenge-based input formats (libwpg, libcdr, libvisio) not supported (see related sections in configure.ac)
- CMake's module for ImageMagick seems outdated and misses defines [1]
- ...
Can you make sure we have a bug or bugs filed on these issues, assuming you aren't planning on just tackling them directly? What do you think about using a new tag in the bug tracker for flagging cmake-specific build system issues? (Or maybe we could reuse the existing build system tag(s) and just filter by date?)
In the past, we tagged cmake-related reports with two tags: 'build' (official tag), and 'cmake' (now added to the official list too). Is this sufficient?
Yep!
I haven't filed reports yet for the listed issues, but will do so next week (if not yet covered by an existing report or solved).
Known issues - OS X:
- failing tests in ConfigChecks.cmake (e.g. to detect existing gtk features) - missing includes/libs for the predefined tests?
- no checks for gtk backend (don't pull in X11 unless used, configure for gtk-mac-integration (future))
- workarounds for linker failures seem too simplistic compared to the tests done by autotools-based build system (--> simply adding '-liconv -lintl' is likely to break on other systems (?))
- Cmake's FindFreetype.cmake module still lists path name of older freetype versions first [2]. This causes cmake to opportunistically detect an older version of freetype which happens to be installed on the local system (Lion's original X11 in /usr/X11R6 --> /usr/X11), completely outside any configured prefixes. Deleting the (incorrect) name in a local copy of the module works around this issue.
- ... (to be continued)
Will you need a separate set of rules for X11-based builds, and for native builds?
Both, but they overlap (for the most parts). For basic builds (without considering packaging as osxapp), we certainly need features to
- avoid including/linking libraries not required by the current backend (only link X11 with X11 backend)
- find required modules which are (or will be) specific to the backend (gtk-mac-integration for OS integration features with Quartz backend)
I haven't looked into or tested packaging-specific issues yet (for example the '--enable-osxapp' configure option from autotools).
Okay, sounds good.
Changes (WIP):
See diff used for local cmake build, currently maintained as gist [3]
Those changes all look good to me, please go ahead and land them. And don't be too shy about checking in more changes; we have a ways to go before these scripts are production ready.
The gist has been updated with a few more changes - if there are no objections, I will commit them later today.
Go for it. If I have time tonight I might work further on cmake stuff, but it's starting to get late so we'll see.
Bryce
On Wed, Apr 29, 2015 at 05:46:05PM +0200, su_v wrote:
Minor update:
On 2015-04-29 08:05 (+0200), su_v wrote:
The major issue I encountered in this initial attempt (apart from the linker failure) is that cmake-based builds seem to prefer to look in hard-coded paths for packages. While it is true that my local test build setup does not use "default" locations (for a reason), I don't think that the build system overall should pose such a limitation to the user.
Ideally, I'd like to learn from cmake-experts how to either prepend search paths (mostly for GTK2-related packages) or change default prefixes via command line when calling cmake, or - if this is not supported by cmake's default Modules or the custom copies which are shipped with inkscape - how to best modify them in such a way that the required changes can be integrated in local build scripts (manually tweaking the config via ccmake or CMakeCache.txt each time is not an option).
houz probably already helped you with all of this, but in general I find that 'cmake -L' is handy for finding what settables there are, and then 'cmake -D<param>=<val>' to set them.
We should include some examples of common kinds of configuration in our README or INSTALL document.
The way the cmake Find modules work, essentially we just give them lists of directories to look for specific header files or library files. So, if for Mac you use a non-default location, but one which other users might use as well, there's no reason we couldn't add that to the given Find module's path list. So if it helps Mac or Windows packaging to have packages built at, say, /opt/inkscape-dependencies or C:\devpkgs123, or whatever, then certainly add those paths to our Find modules to help make life easier.
houz helped me solving the problem how to find GTK2 installed into custom prefix:
- works: setting the env variable $GTKMM_BASEPATH to the custom
MacPorts prefix (in the shell where cmake is run) 2) the module FindGTK2.cmake distributed with Inkscape is outdated (it does not support the Quartz backend of GTK2); this has been fixed upstream in cmake. Removing the outdated copy in Inkscape's CMakeScripts/Modules forces cmake to use the newer version it installed itself (works).
Yes. As it's been a while since cmake was introduced to our repository, likely all the modules in our tree have bitrotted to some degree. These should all be refreshed. Also, I wonder if some of them we can use from cmake directly and not include them in our tree?
Now on to the remaining issues (as in: fix wrongly detected include dirs and libs from unrelated locations, still fails to link, support for GTK+/Quartz hasn't been added to Inkscape's cmake files yet, etc.)
I have been messing with it too, and notice the dependencies for a number of extensions haven't been set up, or were set up as optional. I'm going to be checking in some changes to make them required so that the tree builds on ubuntu. We'll want to give these some more attention in time, so that disabling the dependency disables building the respective extension(s) and so on.
Bryce
participants (5)
-
Alex Valavanis -
Bryce Harrington -
Ken Moffat -
Krzysztof Kosiński -
su_v