Use LibcWrapGenerator to build AppImageKit components about appimagekit

[RazZziel]

Forgot to reference the issue in commit 9570f24, which moves LibcWrapGenerator from .travis.yml to CMake.

Right now, everything compiled in C should be built with this header, but I still haven't tested it thoroughly.

[probonopd]

Compilation is broken right now.

Since we now have external projects using the AppImage codebase like the Subsurface project, I would suggest doing larger changes like these in a feature branch, see whether travis-ci succeeds building, then doing a Pull Request to master and then merge it into the master when we know for sure that the project still builds on travis.

[RazZziel]

Roger that, adopting git flow then

Looks like travis version of CMake is different from mine...

[probonopd]

Building also fails with cmake-3.2.2-Linux-x86_64.tar.gz, claiming attr/xattr.h is missing. Do we have a dependency on libattr1-dev?

[probonopd]

I moved these commits to the experimental branch. The master branch builds again.

Once the experimental branch is ready for primetime, let's do a PR and discuss it.

[RazZziel]

According to the Changelog, CMake impemented XZ in version 2.8.12, so

• bfc2d2d will probably not work, Ubuntu 12.04 LTS Server Edition 64 bit ships CMake 2.8.7
• 82169be will probably do work, Ubuntu 14.04 LTS Server Edition 64 bit ships CMake 2.8.12

Right now the only two dependencies that use CMake are:

• http://www.freedesktop.org/software/desktop-file-utils/releases/desktop-file-utils-0.22.tar.xz
• http://ftp.gnome.org/pub/GNOME/sources/vte/0.43/vte-0.43.0.tar.xz

and both packages are only provided in XZ format; BZ2 nor GZ are available.

[RazZziel]

The XZ issue works on Trusty. I guess using Trusty on Travis is not desirable, because it may change the compatibility of the output, and overall it's a beta distro (for Travis). What do you suggest to update CMake? PPA? Official binary distribution?

Regarding libattr, the fix it's almost there

[RazZziel]

Compilation almost fixed, now it fails when linking runtime because of libcwrap.h
https://travis-ci.org/probonopd/AppImageKit/builds/90264515#L1746

CMakeFiles/runtime.dir/runtime.c.o: In function `md5_buffer':
/home/travis/build/probonopd/AppImageKit/md5.c:178: undefined reference to `memcpy@GLIBC_DONT_USE_THIS_VERSION_2.14'

etc

[RazZziel]

We'll need to take a look at the discussion in https://blogs.gnome.org/tvb/2013/12/14/application-bundles-revisited/comment-page-1/#comment-3830

[probonopd]

@RazZziel Please make sure to not try this in the master branch as expressed in #35 (comment)

I have, again, reverted the changes to the master branch using

git clone https://github.com/probonopd/AppImageKit.git
cd AppImageKit/
git reset --hard eff3e06c573b0455a11ec7499df431d5be33fd83 
git push --force

and this time I have enabled the branch protection features of GitHub, which hopefully means that these changes do not land inadvertently in master again.

We have important projects trying to adopt AppImageKit for use in their build system and we drive them away from AppImageKit if we break (or substantially change) master. One of these projects does not like the fact that, in addition to breaking the build entirely, the changes pull in so many build time dependencies. Which I can really relate to.

Please make extra sure that with your next git push the changes don't land in master again. (If they do, use my procedure above to remove them.)

Once the feature branch is working as intended, then let's discuss what we merge into master and when, and how we announce that.

Thanks!

[probonopd]

The XZ issue works on Trusty. I guess using Trusty on Travis is not desirable, because it may change the compatibility of the output, and overall it's a beta distro (for Travis).

Correct, this is not desirable. Let's continue to target Ubuntu 12.04 LTS as the build system. Using a newer distribution as the build system means it becomes harder to maintain compatibility of the build products with older distributions. Plus, other projects that may want to produce AppImages may not want to use something newer than Ubuntu 12.04 LTS.

What do you suggest to update CMake? Official binary distribution?

I have had positive results with the official binary distribution which I am using in https://github.com/probonopd/AppImages/blob/master/recipes/subsurface.sh

[probonopd]

The use of LibcWrapGenerator should be optional, so that one can choose at build time whether to use it (or not).

[RazZziel]

Finally experimental is building again in Travis. What a dependency rollercoaster ride.

[RazZziel]

The use of LibcWrapGenerator should be optional, so that one can choose at build time whether to use it (or not).

@probonopd defaulting to use LibcWrapGenerator, or defaulting not to?

By the way right now GNU xorriso is used by default, but libburnia can be selected using cmake . -DUSE_GNU_XORRISO=OFF

[probonopd]

Cool @RazZziel I can imagine it wasn't easy. I'd say we should have it use LibcWrapGenerator by default, but also have an option to disable it.

Additionally, an option that really minimizes the build time dependencies if all you want is produce an AppImage for an upstream app project as part of a script that generates the AppImage. (Then you don't probably need more binaries than runtime and AppRun - everything else can be used from the host system). (I think we had another ticket on this, which might really be worth to reconsider now given the load of additional dependencies)

[RazZziel]

Actually, I thought third parties were supposed to use the binary distribution of AppImageAssistant we release every now and then, like they use tar or dpkg-deb.

Anyway, running cmake . && make AppImageAssistant should produce an AppImageAssistant without building all the additional dependencies that stuff like AppImageMonitor has. Actually in theory they could just cmake . && make runtime xorriso, and use AppImageAssistant.AppDir/package script.

[probonopd]

@RazZziel
Is it possible to build the Experimental branch without LibcWrapGenerator?

[RazZziel]

Done:

• cmake . -DUSE_LIBC_WRAP_GENERATOR=ON (default)
• cmake . -DUSE_LIBC_WRAP_GENERATOR=OFF

If you for instance want to change the default, you must edit it on LibcWrapGenerator/CMakeLists.txt:

option(USE_LIBC_WRAP_GENERATOR "Use LibcWrapGenerator" ON)
option(USE_LIBC_WRAP_GENERATOR "Use LibcWrapGenerator" OFF)

[probonopd]

I can compile experimental now (tested on Ubuntu 15.10) with cmake . -DUSE_LIBC_WRAP_GENERATOR=OFF but it fails with undefined reference to memcpy@GLIBC_DONT_USE_THIS_VERSION_2.14 when I just run cmake . - see #44

[probonopd]

Might try this on appimaged, appimagetool and friends now.