I've now done a couple of builds and DESTDIR installs of 0.92pre3 : the dependencies (for gtk2) seem to be the same as for 0.91, at least on (BLFS-7.10)¹ x86_64 linux.
But there are a few things which puzzle me - I really don't grok cmake, but at least inkscape now builds fine with a separate build dir in the conventional cmake manner. But I looked at the files to work out what options were available, and from the claimed defaults I guessed I might have to turn off a few (gnome_vfs, libcdr, libvisio, libwpg) - but in fast those were all correctly turned off without any action on my part.
That makes me even more surprised that WITH_DBUS defaults to OFF. It isn't something I particularly care about, but it seems a common enough addition and doesn't need any odd dependencies (that is, I could turn it on and build without adding anything new on my reasonably-complete system).
But what really puzzles me are the new libs since 0.91 - in my case in /usr/lib/inkscape. What is expected to use these ? I noticed them because by default they are static, although when I added -DBUILD_SHARED_LIB=ON I got (unversioned) .so libs.
For libraries only used within a package, I have no objection to static libs, it's just installing them in /usr/lib which mainly worries me (and technically does not apply here): those might accidentally get linked into something else, particularly if there is no shared lib because of some fubar in my build - and then after a vulnerability fix I would end up with old code in something - the old zlib problem.
In this case, any package using them needs to look for them in $PREFIX/$LIBDIR/inkscape, (sorry for the 'configure' naming) but are they really useful ? And if they are, should not the directory be versioned in case things change ? And finally, is it *acceptable* to you guys to make them shared, or will you tell my users that it is unsupported if they get problems with .so libs ?
Finally, it was disappointing to have to download gtest - not everybody normally runs tests (and I have no idea what the 1 test does, I couldn't find it - like I said, I don't grok cmake ;) For a prerelease it isn't a problem, but it would be nice not to have to do it for a release (i.e. let people build without running tests). Bu the script to download it was at least convenient (although perhaps users behind the Great Firewall might not appreciate it).
I very much doubt that I can produce useful "usage" comments (I keep having to google every time I build it with a new compiler / glibc / gtk / whatever and th en try to test it), but for the moment I won't be installing it until I get clarification about the purpose of the libs.
I've also got another slightly older system (gcc-6.1, gtk+-3.18) where I can test the experimental gtk3 build if that would be useful ?
But overall, this has been much less painful then when I last looked at using cmake for inkscape, so thanks for all the fixes.
1. http://www.linuxfromscratch.org/blfs/
ĸen
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!
https://bugs.launchpad.net/inkscape/+bug/1640899
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
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!
https://bugs.launchpad.net/inkscape/+bug/1640899
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Yes, I saw your reports. There are four differences:
1. I used the prereleae (I'm not _that_ much into bleeding edge), but that difference is unlikely to be material to your problems.
2. You are using 32-bit. Very few developers build on 32-bit nowadays, problems are not uncommon when people such as yourself make the worthwhile attempt to test on i686.
3. The distro you used is old. I assume that LTS in ubuntu means they are unlikely to change package versions (although they might backport fixes). Therefore, problems building new software are to be expected - that is the fun of testing ;-)
4. I think you did gtk3 builds (because of your reference to WITH_GDL_3_6). I don't have libgdl, my comments were for gtk2 because gtk3 is still flagged as experimental. I expect I'll hit a similar problem when I try to build the gtk3 version.
ĸen
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.
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?
As for GTK3, that wasn't an end user choice, that is what trunk uses "out of the box" these days.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
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
On Wed, Nov 16, 2016 at 12:13:38AM +0000, Ken Moffat wrote:
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:
(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.
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.
Indeed, I have got rid of lcms1.
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.
Just for the record, they did use /usr/share. But I get the distinct impression that this seems to be the wrong list for asking questions about the build, and your bug report seems to be equally ignored, so I'll shut up again and for the moment I won't procede with a real install or attempting to test it.
ĸen
On Wed, Nov 16, 2016 at 08:30:29PM +0000, Ken Moffat wrote:
On Wed, Nov 16, 2016 at 12:13:38AM +0000, Ken Moffat wrote:
Just for the record, they did use /usr/share. But I get the distinct impression that this seems to be the wrong list for asking questions about the build, and your bug report seems to be equally ignored, so I'll shut up again and for the moment I won't procede with a real install or attempting to test it.
Following Dr Mo's reply to me on another thread, I tried using the old build, i.e. ./autogen.sh ; ./configure--prefix=/usr
Something odd happened when trying to link inkview at the end (ld failed, but I couldn't see any descriptive error), so I touched src/inkview and d id a DESTDIR. This time, no /usr/lib/inkscape.
I assume that /usr/lib/inkscape with its static libs in the cmake build is an error. I'll raise a bug.
ĸen
participants (2)
-
Ken Moffat -
mathog