Skip to content
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

WIP: Add support for building subprojects with other build systems #4321

Closed
wants to merge 5 commits into from

Conversation

xclaesse
Copy link
Member

@xclaesse xclaesse commented Oct 3, 2018

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.

@jpakkane
Copy link
Member

jpakkane commented Oct 4, 2018

The project will be configured, compiled and installed inside meson's build directory

Almost no project is relocatable. That is, they are only guaranteed to work if installed to their final resting place such as under /usr/local. If the files are anywhere else they are not guaranteed to work and can break in arbitrary ways.

Further this is an "environment setup" kind of action, not a build action. meson.build should not configure external build systems and, in fact, should not even know that such things exist.

@xclaesse
Copy link
Member Author

xclaesse commented Oct 4, 2018

@jpakkane When doing make DESTDIR=/path/to/meson/builddir install all files are in their final state, just not at their final location. So they are not in any "magical" state, we can totally use them. As far as I know the only limitation is we cannot run executables from there, but that's not a use-case I care about.

Again, here we don't have to provide any guarantee, we can just provide a tool that works in some limited scope. Like, for now, we can already use pkgconfig files from there. I don't think we should reject a feature that makes 90% of the use-cases easier, just because we could theoretically think about cases where it won't work.

Further this is an "environment setup" kind of action, not a build action. meson.build should not configure external build systems and, in fact, should not even know that such things exist.

Meson is about making life of developers easier. Ignoring the reality that not all project of the world use meson is not going to help anyone.

@xclaesse
Copy link
Member Author

xclaesse commented Oct 4, 2018

btw, if this is an "environment setup" kind of action, then we can just drop completely the whole concept of subprojects. That's a ton of code in meson that only setup your environment. You can just install each of them manually in the prefix.

@jpakkane
Copy link
Member

jpakkane commented Oct 4, 2018

As far as I know the only limitation is we cannot run executables from there, but that's not a use-case I care about.

Wouldn't the installed projects' pkg-config files point to the wrong place (i.e. the DESTDIRless install dir) and thus the output would not be usable because the libraries are not there?

@xclaesse
Copy link
Member Author

xclaesse commented Oct 4, 2018

That can be fixed by setting PKG_CONFIG_SYSROOT_DIR, my PR does that.

@xclaesse
Copy link
Member Author

xclaesse commented Oct 5, 2018

Ok, changed my mind about generating a meson.build from wrap file, it's too complicated. The wrap file could just have the path to a meson.build file to copy inside the subproject. I did that in a separate PR #4327.

@xclaesse xclaesse force-pushed the external-project branch 3 times, most recently from 9c9618b to f74c058 Compare October 6, 2018 18:57
@xclaesse
Copy link
Member Author

xclaesse commented Oct 6, 2018

Here is an example of meson.build file to build ffmpeg:

project('FFmpeg', [],
  meson_version : '>=0.48.9',
)

mod = import('unstable_external_project')

p = mod.add_project('configure',
  options : ['--prefix={prefix}',
             '--libdir={libdir}',
             '--incdir={includedir}'
            ],
)

libavfilter_dep = p.dependency('libavfilter')
ibavformat_dep = p.dependency('libavformat')
libavcodec_dep = p.dependency('libavcodec')
libavutil_dep = p.dependency('libavutil')

And this is to build AOM, a cmake project:

project('aom', [],
  meson_version : '>=0.48.9',
)

mod = import('unstable_external_project')

p = mod.add_project('cmake',
  options : ['-DCMAKE_INSTALL_PREFIX={prefix}',
             '-DCMAKE_INSTALL_LIBDIR={libdir}',
             '-DCMAKE_INSTALL_INCLUDEDIR={includedir}',
             '-DBUILD_SHARED_LIBS=1',
            ],
)

aom_dep = p.dependency('aom')

Both are working pretty well in gst-build.

@xclaesse xclaesse force-pushed the external-project branch 3 times, most recently from 950538e to 713ab48 Compare October 6, 2018 20:18
@xclaesse xclaesse force-pushed the external-project branch 2 times, most recently from c1435f7 to 88610b5 Compare October 6, 2018 20:28
@xclaesse xclaesse force-pushed the external-project branch 5 times, most recently from 5ac8480 to 07cf0fe Compare October 7, 2018 01:16
@xclaesse
Copy link
Member Author

With this extra patch, I successfully cross compiled ffmpeg for Android with gst-build.

Sometimes the subproject's build system is simple enough that it can be
done in a single meson.build at the root of the subproject's directory.
In that case it is overkill to create a tarball.

This will be especially important when we'll support building projects
with other build systems than meson, the subproject's meson.build could
consist only of a few lines calling into external build systems.
This adds an experimental meson module to build projects with other
build systems.

Closes: mesonbuild#4316
This ensures that external project uses the same pkg-config environment
as meson, with the addition of meson-uninstalled directory to be able to
depend on libraries built by meson itself.
@xclaesse
Copy link
Member Author

xclaesse commented Apr 7, 2020

Let's close this PR, I'll open a new one with revisited code.

@xclaesse
Copy link
Member Author

xclaesse commented Apr 7, 2020

For those interested, let's continue there: #6920.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants