-
Notifications
You must be signed in to change notification settings - Fork 441
add ability to exclude libs from a user specified list of folders. #292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Thanks for your contribution, although I don't know Snapcraft well enough to make full sense of it. In order to leave little room for users to produce non-working AppImages, I'd rather hardcode the $SNAPCRAFT_PART_INSTALL,/snap/core
and have a -snap
option, similar to the existing -appimage
one, and have linuxdeployqt
"do the right thing" without the user needing to do manual work.
@zyga what do you think?
Your proposal would work for me, provided $SNAPCRAFT_PART_INSTALL was fetched from the environment. It wouldn't help the use case in #242. It might or might not work in the future when snapcraft supports a newer core that may or not be named core18.
However, my use case is a bit odd. I am not using Qt from ubuntu packages. I am taking advantage of the knowledge in linuxdeployqt to minimize the bits of Qt that get deployed, and to deploy the necessary bits that aren't so easy to trace through ldd, e.g. plugins, QtWebEngineProcess, etc. Also note that I had to structure my snapcraft parts in a bit of an odd way to get the -exclude-folders to work as mentioned above.
snapcraft has methods to deploy Qt apps, but they appear to force me to use Qt from ubuntu packages, which aren't new enough for my app. Thus I haven't evaluated them.
So to claim this is the right way to work with snapcraft as implied by a general -snap option is perhaps a bit too presumptuous. On the other hand, I was encouraged about a general need when I saw the same need to exclude libs from a given folder in #242. Therefore I would support a general -exclude-folders option, but I wouldn't claim enough knowledge of snapcraft to claim that the hardcoding you suggest is going to be useful in general with snapcraft.
I need to preface this by saying that I am really not experienced in Snapcraft or snaps at all, but maybe @zyga can add perspective. If I am getting it right, then you have essentially two options:
- Use the Qt provided by Ubuntu as a snap
- Bundle your own (minimized) Qt inside the snap of your application (kinda what
linuxdeployqt
does - I assume you could just put the resulting AppDir into a snap?)
What you are proposing seems to be something different?
I guess we need some advice from someone who knows how the snap system is supposed to work ;-) in the meantime, have you tried AppImage? ;->
I tried AppImage, I reported the only trouble in #35. Much easier than snapcraft, and a smaller image as well. I first tried Centos 6 because of the comments on https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages. However the resulting appimage crashed on closing. I then tried Centos 7, and the appimage seems to work without issue. Would you recommend Ubuntu 14.04 or Centos 7 for a base system to maximize compatibility given my trouble with Centos 6?
I've personally had great results with Ubuntu 14.04 and Qt from https://launchpad.net/~beineri/ but that doesn't mean that CentOS 7 couldn't also work. I just haven't had the need to try it. So Ubuntu 14.04 is the best-tested option.
This accomplishes one of the goals of #242 in a more generalized way. It allows a list of folder names to be given instead of a single folder.
This is useful to me when using snapcraft on a Qt based project. By using this new option with the values:
-exclude-folders=$SNAPCRAFT_PART_INSTALL,/snap/core
linuxdeployqt will excluded libraries from the core and libraries from packages added with stage-packages which are in $SNAPCRAFT_PART_INSTALL during the build. The libraries from /snap/core won't be included in the snap. The libraries from any staged packages will be in the snap, but snapcraft will deal with them. linuxdeployqt deals only with all the Qt bits.
To get this to work for snapcraft the Qt bits must have been staged by another part that is built before the part using linuxdeployqt. This is necessary so they are not in $SNAPCRAFT_PART_INSTALL for the part using linuxdeployqt, but they will be in $SNAPCRAFT_STAGE.