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