Investigate Meson build system #205
Comments
|
Very interesting indeed! |
|
It looks like the Meson developer had a similar idea!
Summary:
|
|
Sounds intriguing.
I think we should contact the author and ask him whether he would be interested in AppImage as a target. Since he writes "a binary that bundles its dependencies" but actually the script seems to generate an "archive"... |
|
Yes it's probably worth talking to him. I'm really busy at the moment - won't be available until the end of the month - but feel free to start a discussion without me. It would probably be a good idea to have a quick go with Meson first, maybe copy his example project, and see whether his tools can locate and bundle indirect dependencies. The next step would be to implement a blacklist of system libraries. |
|
Hi, I'm the main Meson developer. Our goal is to make it easily build to any package format, whether it be AppImage, msi installer, dmg or flatpak. I have not looked too deeply into how AppImage organizes itself, but presumably it is mostly a question of setting up paths correctly when doing install and building all dependencies that are not provided by the base system. The former is done with command line arguments to Meson and the latter by having said deps available as wraps. |
|
Hi @jpakkane and welcome to AppImage; glad you found here. I would roughly compare an AppImage to what is an For an introduction see our wiki, especially the part of how to create portable AppImages. When in doubt, consult the AppImageSpec. Key to AppImages that run on not just the most recent but also on older distributions is that the part of the dependency graph which is not supposed to be bundled, starting from glibc, is not more recent than what can be expected to be part of the target system(s). I recommend library versions from the debian oldstable or CentOS 6 era for this reason. Of course, those dependencies that will be bundled inside the AppImage may be more recent than that. A rule-of-thumb for what should be bundled: "Everything that cannot be reasonably expected to be part of each target system in a recent enough version" - namely, everything except these libraries. Please let me know here if something is unclear, doesn't make sense, or if you get stuck. Again, welcome! |
|
From what I can tell of the documentation, all a project needs to do to support AppImages is to install the AppRun shell script and the PNG image (+ maybe help and the rest). This is quite straightforward and requires no changes in Meson, it can stage an appdir just fine. |
|
@jpakkane Thanks for checking in on AppImages! Your assessment is pretty accurate. AppImageKit is a very capable tool for making AppImages, and making a _(very basic)_ AppImage is just a case of adding the AppRun script, icon and .desktop file. There's no changes needed to Meson there, but here is where you might be able to help us: 1. Detect (and bundle) indirect dependencies:Where it gets tricky is making the AppImage truly portable, as this involves bundling not only the program's direct dependencies, but also it's dependencies' dependencies and so on. It is already possible to detect these dependencies using 2. Detect (and bundle) runtime dependencies:A major problem is where some dependencies are loaded dynamically at runtime and are not detectable using the usual 2. Excluding dependencies provided by the base-systemIt is desirable to exclude all libraries that can be guaranteed present on any Linux system to prevent the AppImage becoming too large. Since there is no standard Linux base system this means developers currently have to use trial and error to see what they can get away with not including. I think that (1) can be automated within Meson, but (2) and (3) probably require lists to be manually defined. It would be great to be able to have these lists defined centrally somewhere and then have Meson use them to determine what needs to be bundled. The lists would look something like this: # Qt Plugins dependencies:
libfoo
libbar
libbaz
...# Linux base system:
libfoo
libbar
libbaz
...If Meson was used to package an application that depends on Qt Plugins then it would include everything on the first list and exclude everything on the second list. |
For the list of libraries that are expected to come with the base system and hence should not be bundled, this list can be used. |
|
Whoever does the work decides which tools to use 💯 |
|
I'd go for CMake (see #408). Most IDEs and other tool sets support it, it's widely spread and well tested. Although it might not be as elegant as meson, it's probably the better decision to go for CMake. |
|
Transitioning to CMake in the near future. Partial implementation is available already. Closing this issue. |
|
Why I absolutely dislike Meson: |
TLDR: Meson appears not to work on Ubuntu 14.04 LTS despite the fact that 14.04 is still supported by Canonical (or was until the 25th of April this year). This is apparantly because Meson depends on a newer version of Python than is provided for that distribution. However, Meson's CI tests run on Ubuntu 14.04, so the above conclusion may not be entirely accurate. Anyway, Ubuntu 16.04 is now the oldest supported Ubuntu LTS, and there are good reasons to consider switching to it. |
This is not entirely accurate. The CI uses a Docker image that is based on Ubuntu 18/10. |
Thanks for the clarification @jpakkane. Perhaps you would consider switching to something a bit older in future because most people use whatever Travis currently uses. |
|
Hi @jpakkane. In this project, we care about building applications for the oldest still-supported long term stable distributions, e.g., CentOS 6, Ubuntu LTS, and so on. Hence, to make it feasible to use Meson for this purpose, it would be good if Meson was developed on say, CentOS 6 and accept no dependencies that are newer than what is shipped with it. I realize that our demands are a bit special, so if building on the oldest still-supported long term stable distributions is not in the scope of Meson, then Meson is not a good fit for our purpose but may still be fine for other use cases. |
|
Well, meson as a build system wouldn't be problematic strictly in terms of dependencies; we can build additional ones. But then again, that's annoying work to do. So I agree with @probonopd. |
|
That being said, an AppImage that would contain Python, Meson, and ninja and that could run on all still-supported LTS distributions might be beneficial for the Meson project to have - it would allow users to use Meson without having to worry about incompatible Python versions and such, which currently makes using it cumbersome. |
|
As a build system, Meson should really target the oldest distribution possible. This should be by default, for CI Tests and everything, not just as an optional AppImage build for those that want it. Application developers sometimes have to choose between supporting older systems or gaining access to features only provided on newer systems, but they don't expect this decision to be made for them by their build system. While Meson builds against Ubuntu 18.10 there is a genuine risk that it might not work with Ubuntu 18.04, which is the latest LTS. Most users and developers use LTS releases, so at the very least Meson should support the latest LTS, and preferably the one before that too. |
|
We do our best to support things, but our test matrix is really big. Running tests is already fairly slow. Adding even more platforms will quickly become unfeasible. The only "real" dependency we have is Python 3 and we do have 3.5 in our test setup (on Windows IIRC, but it's there nevertheless). Thus far we have not received many (or any?) bug reports about things breaking in old LTS versions. The version of Python required is the oldest that is available from the system in Debian Stable, latest Ubuntu LTS and in the future probably also the latest RHEL. |
|
What we are asking for is to go for the oldest still-supported rather than the newest LTS. It should not increase the test matrix because what runs on old systems is supposed to also run on newer systems. |
|
In other words, if you can only support one platform, pick the oldest one and you get the newer ones for free. That's what Qt and everybody else does. |
Newer Python versions can sometimes break in subtle ways, so that's not always true. That said, if you have to choose between testing on an old and a new version, it's probably better to test on the old version. |
That's true, but that's arguably a Python bug so not something you'd have to worry about. In any case, you can rely on experienced users to test and fix bugs on new systems whereas people on older systems tend to be less experienced (though not always), and the bugs on newer systems are likely to be smaller and easier to fix than if a dependency is completely missing on an old system. |
Meson is a build system which is designed to solve the problems with existing build tools like make, automake, Cmake, qmake, etc. It is designed to be fast and simple to use. It has an interesting dependency management system that might make it ideally suited for building AppImages - either through scripts or by adding native AppImage support directly to Meson.
https://github.com/mesonbuild/meson
http://mesonbuild.com/
http://www.admin-magazine.com/HPC/Articles/The-Meson-Build-System
Highlights from Meson presentation video on YouTube:
Native AppImage support could take the form of an
--AppImagecommand line option for Meson which would not only build the application, but would also locate all of the necessary libraries and components and copy them into the build directory (i.e. it would create the AppDir).The text was updated successfully, but these errors were encountered: