search

mesonbuild / meson

The Meson Build System
http://mesonbuild.com
Apache License 2.0
5.62k stars 1.63k forks source link

Accessing top-level project variables from subproject #2844

Open alyst opened 6 years ago

alyst commented 6 years ago

Is it possible to re-use the dependency declared in the top-level project from the subproject?

Motivation

My main project depends on BLAS library and its subproject (say, 'MUMPS') also depends on BLAS. There are multple BLAS implementations around, but I want to use the same BLAS dependency in both.

It is already working with if BLAS is provided by a subproject (say, 'coinblas'), then I can use subproject('coinblas').get_variable('BLAS_dep') from 'MUMPS' subproject. What I want is superproject().get_variable('BLAS_dep').

polarina commented 6 years ago

Why is it not sufficient for the main project to get and use the subproject's BLAS dependency?

alyst commented 6 years ago

Why is it not sufficient for the main project to get and use the subproject's BLAS dependency?

Because the subproject (MUMPS) is optional. It's the default linear solver, which is built and used in the absence of the other solvers. But BLAS is required both by MUMPS and Ipopt. If MUMPS is not used, we just don't attempt to process its wrap file, so we even have no meson.build for it.

QuLogic commented 6 years ago

Only one copy of a subproject will exist in the top-level directory (according to the manual at least), so I'm not sure why you can't request BLAS in both MUMPS and your top-level project (without any get_variable hacking) and have it work properly.

alyst commented 6 years ago

I'm not sure why you can't request BLAS in both MUMPS and your top-level project (without any get_variable hacking) and have it work properly.

Because BLAS is a dependency, not a subproject. This dependency could be provided by a subproject (default fallback BLAS implementation coinblas), but it also could be an external dependency. Theoretically I can replicate the logic of processing BLAS dependency both in Ipopt and MUMPS meson.build files. Then I would have to keep this logic in sync. Or I can put this logic into yet another subproject (in the absence of user functions). But superproject() seemed much simpler alternative. It doesn't look like a hack to me, because subproject('foo').get_variable('bar') technique is described in the manual. As it could be used to refer from one subproject to another one (which have already been processed), referring to the main project is not much worse. It doesn't introduce circular references, just allows to look up to the current state of variables.

nirbheek commented 6 years ago

What you really want to do here is to add support for BLAS as an External Dependency in Meson, so people can do something like blas_dep = dependency('blas'), and the same for lapack, etc. The same way Boost works.

This will ensure that the same blas is used by all (sub)projects. In fact, it will be cached so meson won't even look it up twice.

nirbheek commented 6 years ago

subproject('foo').get_variable('bar') technique is described in the manual

This is not the recommended way to handle external dependencies with subproject fallbacks. For that, you do something like this:

blas_dep = dependency('blas', fallback : ['coinblas', 'BLAS_dep'])

This would search for blas on the system, and if it wasn't found, would configure the coinblas subproject and search inside it. Is this what your blas-search logic is in the parent project?

alyst commented 6 years ago

What you really want to do here is to add support for BLAS as an External Dependency in Meson, so people can do something like blas_dep = dependency('blas')

That's probably true. But e.g. FindBLAS.cmake looks quite scary for me to embark on writing a similar thing for Meson. Also I'm not sure that it would be easy/possible to make the logic of dependency('blas') universal to fit the logic of all projects that may use it.

If/when dependency('blas') would be there, then yes, blas_dep = dependency('blas', fallback : ['coinblas', BLAS_dep]) looks like a way to go.

nirbheek commented 6 years ago

That's probably true. But e.g. FindBLAS.cmake looks quite scary for me to embark on writing a similar thing for Meson.

That's fine, it doesn't have to be perfect. Rome wasn't built in a day. Implement something that works on your Linux distro, add tests for that, and others will extend it to work on their OSes. I can help you with the code if you need assistance.