On Tue, Nov 15, 2016 at 10:40:57AM -0800, mathog wrote:
On 15-Nov-2016 09:29, Ken Moffat wrote:
On Tue, Nov 15, 2016 at 08:58:16AM -0800, mathog wrote:
On 14-Nov-2016 17:28, Ken Moffat wrote:
this has been much less painful then when I last looked at using cmake for inkscape
I wish I could say the same!
Yes, I saw your reports. There are four differences:
This is what a build system is supposed to do - detect and handle exactly these sorts of differences! Here there is a case where it detects a version difference but does not handle it (gdldock), another where it confuses the two installed versions of a library (libcms/libcms2), and two others where it is just acting oddly (inconsistent /share/locale vs. /usr/local/share/locale, using CONCAT when this version of cmake doesn't support it.) It seems to be amazingly variable in its behavior on Ubuntu 14.04 lts: it did 3 different things on 3 different systems, when the three machines were as identical, in terms of the versions of the relevant packages, as we could make them using the "apt-get dist-upgrade" mechanism.
Sometimes we all need to remember that cmake is still comparatively young. Various things seem to have changed in its different versions, and fewer people have had to try to fix problems with it. Compare configure scripts, where many are based on autotools and pull in a lot of accumulated knowledge : newer versions of the packages they are looking for can still require changes.
I don't know anything about cmake. Are these the sorts of issues it typically has, or are they bugs in the cmake scripts written specifically for Inkscape?
I can't comment favourably on cmake, as a 'nix user I regard it as a way of inventing a wheel with many sides (so not a square wheel, but not as smooth as a good configure script). But people on windows, and perhaps on mac, seem to like it. And even I now have to build it fairly early in my (from source) desktop builds because of the packages which have swi tc hed to it.
As I said, I don't really understand its organization (e.g. I couldn't find what the tests actually run)
The gdldock issue looks like the sort of thing where it got changed for some newer version, but probably needs more changes for some specific version.
For lcms I don't recall if the s ystem where I tested had the old lcms1, or whether I've now got rid of that entirely.
As for GTK3, that wasn't an end user choice, that is what trunk uses "out of the box" these days.
From reading this list, I had the impression that 0.92 was going to
be for changing to cmake, and whatever comes next will be for gtk3. Certainly, gtk3 appears to still be marked as experimental in pre3 - but of course trunk might be in advance of that (i.e. for future development).
Maybe pre3 shares those issues, maybe it doesn't.
The source is still a bit of a pain, probably too many devs using windows:
find -type f | xargs grep LOCALE ends with an error message - grep: ./src/libdepixelize/!PLEASE: No such file or directory
On other invocations xargs complains about an unmatched single quote and seems to stop.
But LOCALEDIR is defined at #define LOCALEDIR (br_thread_local_store (br_prepend_prefix ((void *) "", "/share/locale"))) in src/prefix.h
Recall that I didn't actually do a real install, and I'm on a different machine at the moment (testing today's firefox release) so I don't know for certain if my DESTDIR builds yesterday did use /share or /usr/share. Will try to come back to this, but it might take a while - yesterday things were quiet and I was stalled on my background task; today things are busy plus I finally worked out the problem in the background task (fonts - some directories were 700 perms instead of 775, but not all of them).
This system hasn't got the deps for me to try building inkscape, and I'll be using a different system on it to try building the new Xorg server - probably with libXfont2 instead of libXfont, depending on how much has to fall out with libXfont.
Meanwhile, good luck.
ĸen