CircleCI #3921
CircleCI #3921
Conversation
|
Don't switch. Just add. |
|
@gi0e5b06 No, there's no point in running the same tests twice, so we'll abandon one of the services eventually. Also, these are services generously offered to us at no cost, so I'd like to avoid using more resources than we need. |
cmake/linux/package_linux.sh.in
Outdated
| APPIMAGETOOL="$USERBIN/appimagetool" | ||
| LINUXDEPLOYQTDIR="$HOME/bin/linuxdeployqt" | ||
| LINUXDEPLOYQTBIN="$LINUXDEPLOYQTDIR/usr/bin" | ||
| LINUXDEPLOYQT="$LINUXDEPLOYQTBIN/linuxdeployqt" |
There was a problem hiding this comment.
$HOME/bin/foo is a search path for some of these portable tools and they were chosen that way for a reason. If fuse isn't supported, $HOME/bin/foo/bin/foo doesn't make sense.
Perhaps we just keep a squashfs-root folder to be consistent with upstream documentation. Also, according to the documentation, we should always execute the AppRun executable to setup the environment properly. This may not be an issue now, but we don't want to use the app other than how it was intended, and furthermore the AppRun can itself point to a wrapper around the launcher.
But the more I think about this the more I wonder if we should have the non-fuse logic as some sort of detect-and-fallback so that people that do this locally can continue to have a copy of the binaries in the default $HOME/bin location?
There was a problem hiding this comment.
Another idea (assuming we detect-and-wrap the fuse logic) is that we can also symlink to $HOME/bin/foo and point it to the AppRun, thus simulating what fuse would have done. Circle-CI may not be the only desktop with FUSE turned off. I remember @jasp00 not liking the reliance on FUSE either.
There was a problem hiding this comment.
Here's some inspiration around a wrapper, authored by one of the appimagetool maintainers. https://github.com/TheAssassin/redeclipse-appimage/blob/master/build-appimages.sh#L94-L96
cmake/linux/package_linux.sh.in
Outdated
| DAYSOLD=2 | ||
| if env -i which linuxdeployqt > /dev/null 2>&1; then | ||
| skipped "System already provides this utility" | ||
| elif ! find "$LINUXDEPLOYQT" -mtime -$DAYSOLD 2>/dev/null|grep -q "." > /dev/null 2>&1; then | ||
| elif ! find "$APPIMAGE" -mtime -$DAYSOLD 2>/dev/null|grep -q "." > /dev/null 2>&1; then |
There was a problem hiding this comment.
Just a side-note, I wrote-but-passionately-hate having this internal logic. If there's a submodule we can clone offering a curl|wget binary caching method, we could simplify this. (or move it to another script?)
| @@ -84,7 +84,7 @@ IF(NOT DEFINED ENV{MINGW_DEBUG_INFO}) | |||
| MESSAGE("* CMAKE_CXX_COMPILER : ${CMAKE_CXX_COMPILER}") | |||
| MESSAGE("* CMAKE_RC_COMPILER : ${CMAKE_RC_COMPILER}") | |||
| MESSAGE("* WINDRES : ${WINDRES}") | |||
| MESSAGE("* ENV{PKG_CONFIG} : $ENV{PKG_CONFIG}") | |||
| MESSAGE("* PKG_CONFIG_EXECUTABLE : ${PKG_CONFIG_EXECUTABLE}") | |||
There was a problem hiding this comment.
Can you confirm this was available in CMake 2.8.9 ?
|
This could be a way to maintain a correct and up to date list of dependencies needed on common linux distro by using the corresponding (official) docker imager, e.g. debian:testing, debian:unstable, fedora:latest etc. I used to do this with gitlab-ci. It's much more easier than maintaining a wiki as we know clearly if the list is correct, and are warned when it's not anymore. |
|
They currently also support macOS builds: https://circleci.com/build-environments/#apple-platforms |
# Conflicts: # cmake/linux/package_linux.sh.in # Use 'master' version
|
The use of |
| echo " [.......] Downloading ($(uname -p)): ${url}" | ||
| wget "$url" -O "$LINUXDEPLOYQT" -q || (rm "$LINUXDEPLOYQT" && false) | ||
| wget -N -q "$url" || (rm "$filename" && false) |
This PR adds tests on CircleCI. CircleCI uses Docker containers to run builds in and allows us to specify the Docker image to use. The ones in use in this PR can be found at lukas-w/lmms-ci-docker. I suggest we move that repo to the LMMS organization.
Reasons to use CircleCI:
installstep on Travis). Also, builds on CircleCI start almost instantly, Travis builds however can take a couple minutes to start.@tobydox's new mingw PPA, his old one (targeting 14.04) will not receive any updates.CircleCI says they are working on supporting macOS builds and builds on different CPU architectures in the future. Configuration is a bit less intuitive than Travis, I had to use some advanced YAML syntax to avoid too much duplication, but I think it's still worth the switch.
I suggest we merge this and test it for a while to see how we like it and to decide if we want to drop (Linux) Travis builds in favour of CircleCI.
Tagging @tresf because I had to make some changes to the AppImage build scripts. Fuse is not supported inside Docker so I changed it to extract all of
linuxdeployqt.AppImagecontents.MinGWCrossCompile.cmakeneeded fixing because for some reasonSET(ENV{PKG_CONFIG}wouldn't work.PKG_CONFIG_EXECUTABLEserves the same purpose so the change should be harmless.