-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
RFC: Add minimal support for autotools subproject #4316
Comments
I'll try to work on a PoC PR to see how it can looks like in practice. There are 2 key elements I had in mind when doing this proposal:
|
I don't think this should be autotools specific.. Instead you could do something much more generic along the lines of CMake's ExternalProject.. https://cmake.org/cmake/help/latest/module/ExternalProject.html |
Yeah, of course here I say "autotools" but it could be anything that has "configure/build/install" kind of steps. But I would like to keep it simple at least for a PoC, it can always be generalized later by creating a new meson module and share common code. So here I would like to start small, and grow from there, to see how it goes. |
The declaration should be outside of Attempting to do anything within the same build dir such as using libraries without installing them is not ok. It will not work. That being said maybe we could do something simpler to achieve the same thing. Something in the vein of what Flatpak manifest files do. That is, we would have a file that looks like this:
And then have a command such as |
I like Jussi's plan, just one extra request, I assume those older deps may not have .pc files, so having a nice way to generate them from this would be a nice plus. |
Presumably the build definition would have all the The "correct" fix for any project missing .pc files is to submit a PR upstream to add them. |
About the JSON example you posted, that's basically a .wrap file, we can just reuse that for the download part. About extra prepar-external-dependencies command, I don't think it's useful, it can be part of the normal meson configure when master project calls subproject() |
Btw, it's going to install in master project's build dir, not on the system, so you'll have to tell cc.find_library() or pkg-config to search there. |
Note that one important idea here is using external project as fallback if it's not provided by the distro, that can only be known at configure time of master project. |
No! They should be installed in some sort of final destination (preferably the same where the current project will end up eventually). Otherwise you'd have to reinstall them again upon final install and all things pointing to the file system such as .pc files and install time rpaths will be wrong. |
You probably don't want to install the headers, etc of the subproject publicly in all cases. We have the somewhat common case where you want to "hide" the dependency by building it statically and linking it into the final project. |
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
No, the whole point here is to not have to install in a prefix, otherwise why would I use meson to do that? I could just run configure & make install myself, or use jhbuild/cerbero, that's what they do. The whole point here is really to have autotools projects as fallback when the dependency is not found on the system.
Yes, and why is that a problem? Also in my usage at least, there is no installation step, when I develop with GStreamer, I run the code uninstalled.
.pc files are correct because I compile with the final --prefix, but install with a DESTDIR. Those pc files are usable by meson by setting PKG_CONFIG_SYSROOT_DIR I think (didn't work on that part yet).
That's actually the only issue I see in my WIP pull request, meson sets the rpath correctly to run uninstalled, but upon install the rpath is not rewritten/removed. I'm sure that can be fixed, but I haven't looked at rpath handling yet. |
One important use-case is to build everything once and install it into a prefix which is then distributed to people, with just |
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems (atm only configure/make). The project will be configured, compiled and installed inside meson's build directory and during meson's configuration phase. Closes: mesonbuild#4316
Hi, I would like to know if there is way to link static_library with autotools generated archive files. link_with keyword argument does not work with custom_target. I have two autotool dependencies that one will be static linked to main library and the other one(python) will need to be installed into final destination and link with application. Both dependencies are fairly large and complex autotools build system. This RFC feature is really needed. |
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
This adds an experimental meson module to build projects with other build systems. Closes: mesonbuild#4316
Some projects like GStreamer has many external dependencies that does not have native meson build systems.
Subprojects are really useful to build a project on platforms that doesn't have any of its deps, like cross-building GStreamer for Android. Adding them all in wrapdb is an infinite wast of time. It would be a huge time saving of meson could just run configure/make itself for subprojects.
In the master project (e.g. GStreamer):
In subproject's meson.build:
Would be nice to also be able to use
.pc
file generated bymake
inautotools.declare_dependency()
, but that would mean running make at meson's configure time... Maybe that would be acceptable since this autotools module is really just a "best effort" to help developers, not something nice and clean.Also, I wouldn't be too worried about properly rebuild autotools subprojects if they change, IMHO the use-case here is really to provide fallback for deps that won't change. Again, this is just a "best effort" case, developers can always to rebuild from scratch if something goes wrong (often the case with autotools itself anyway).
And finally, since it's easier to use vanilla upstream tarball/git, the small subproject's
meson.build
could be generated from the.wrap
file, by addingbuild_type=autotools
.The text was updated successfully, but these errors were encountered: