Common .build file for multiple projects

[ghost]

Hi,

What is the best way to have a common .build file that sets common variables for unrelated projects I make, to avoid rewriting the same rules every time in each top project directory.

Please note, those projects are independent.

Thanks,

[ghost]

I am not sure if ny request was clear:

I would like to have a file with compiler options, that I commonly use among multiple projects.
Another with some library custom paths.

And I would like to import those files in the current project dir to be able to pick what I want from them. Like a dictionary meson could understand.
That way, there is a single point of modification when I want to modify an option before rebuilding.

Thanks

[xclaesse]

Meson cannot include a file, it can only do subdir(). If your projects have a common subdir that could do the trick.

This has been requested many times e.g. #3557. The main reason for not allowing that is because we don't want people to turn that feature into some form of function implementation. Most of the time when there is a need for this it means we should rather add API in meson to avoid it, which benefit everyone instead.

[xclaesse]

I've always been in favor of non recursive implementation, said it 5 years ago: #3557 (comment). But IIRC @jpakkane wasn't a big fan of this even if it's included once, but maybe that was not a strong opposition?

But that said, when there is so much boilerplate that you feel the need of a include file, it should raise the question whether we should provide better generic API for what you need, or make sure you actually need what you think you need :P Maybe post concrete snippet of your intended usage, and we could debate if it make sense and if we could reduce that boilerplate.

[ghost]

Yes sure, overall, this is my need:

I have 25+ medium sized C++ packages (read static libs) that I wrote and use daily. They are packages solving different kind of computing problems. So they need to stay separate.

I like to have them in sync as far as compiler version is concerned, without setting the environment variable because it may affect other builds I have on my system.
I use LTO, hence the versioning/compiler requirement. Depending on the project I am working on, I select some of my packages directly in CMake and link them in my final executable.

It enables me to import just what I need and let the compiler do all the hard work.

In my "imported CMake files" you will find some common definitions on my systems, like custom paths, compiler version, some common compiler options that I want enabled and the same for all my packages.
That way, if I need to add a def or update one, I just modify one file and rerun my custom script to rerun CMake + Ninja.

This is "just" convenience, but it saved me a lot of time, avoids typing issues, and enables me to stay in sync my packages in a few seconds (bare the minutes of re-compilation of course) and stay confident everything is setup properly.

Having subdirs would make me to symlink those libs and create a local .build into a local directory.. I would prefer not having to do so, it's cumbersome and creates arbitrary relationship at multiple levels; While having the dependencies set at the top of the current project means only one point of correction/deletion/update. It has my preference.

I don't import non library code into different projects, to make sure everything is encapsulated and the module is growing along my needs, having methods reusable really quick for any project I will have -> productivity gains).

This is the method I use to stay quick to deliver works. Maybe there are better ways and I am open to discuss it.

[ghost]

Some CMake examples, as requested:

cmake_minimum_required(VERSION 3.27)
include_guard(GLOBAL)
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS ON)
set(HEADER_FILES_workspace ${CMAKE_SOURCE_DIR}/../../)
...Some other options
set(CMAKE_EXE_LINKER_FLAGS -fuse-ld=mold)
set(CMAKE_CONFIGURATION_TYPES "Debug" "Release")
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION_RELEASE ON)
set(STATIC_libs ${HEADER_FILES_workspace}/path/to/static_libs)
set(LIBS_TYPE "$<$<CONFIG:Debug>:_dbg>")

cmake_minimum_required(VERSION 3.26)
include_guard(GLOBAL)

set (MAGICKCORE_QUANTUM_DEPTH 16)
find_package(ImageMagick COMPONENTS Magick++ REQUIRED)

it gives an idea, I have another one for opencv as well, compiler versions..

[eli-schwartz]

So it looks to me like what you actually want is https://mesonbuild.com/Machine-files.html

This allows you to specify binaries such as the compiler/linker to use, as well as any built-in or project options -- and that includes the std, whether to use LTO, the build type, the msvc CRT to use, whether to build static or shared or both libraries, what CFLAGS to use...

In fact, meson intentionally refuses to allow specifying the compiler binaries or the definition of a cross build setup etc. in a meson.build, because our principled stance is that this leads to tangled build definitions that are hard to understand and end up bitrotting, and aren't even the responsibility of the project in the first place! Absolute paths to compilers are especially bad because they'll just break on other systems, even if it's the same version of the same compiler brand.

Machine files are designed to be solely responsible for this, and can be reused across projects by specifying them as an argument to the setup command.

[ghost]

Thanks Eli, it looks like a 100% fit for my need.

meson setup builddir/ --cross-file first.ini --cross-file second.ini --cross-file third.ini
so we can't have them defined inside the meson.build instead of the command line ? (It would be cleaner in order to "save" the settings instead of a volatile command)