Add build target keyword parameter 'build_dir'

[keith-packard]

This allows the user to place the build products in a subdirectory of
the build directory, which is useful when multiple build products have
the same base filename.

Signed-off-by: Keith Packard keithp@keithp.com

Here's a possible solution to issue #4019 -- instead of a different base filename, this places the target in a subdirectory so that the basename remains the same in case that is required for the target to be generated correctly.

[jpakkane]

One of the design points of Meson has been to not allow users to influence where things go in the build dir. This simplifies things because then we can depend on directory layouts because we define everything about them ourselves.

There is already a simple way of doing this, which is specifying the two targets in different subdirectories (for example, specifying one shared_library in src and the other in src/otherdir. This was not possible with older versions of Meson but new versions do support it.

[keith-packard]

The problem with requiring separate source directories is that those need to exist before running meson itself, and be populated with meson.build files. That would require a pre-processing step in my build process to generate those directories and add suitable meson.build files. And, those pre-processing steps are target specific, placing what are effectively build products in the source directory. Ick.

Being able to contain the entire build process in a single system and keeping build products out of the source tree has tremendous benefits for maintenance going forward.

As for controlling the build environment, using an explicit variable allows us to migrate existing projects which currently include directory names in their target name to this new mechanism which at least makes the extra name component explicit, rather than implicit. The build system could then choose to manage the build directory layout however it likes, as long as the base filename of the target were allowed to be the same as the base filename of another target in the same source directory.

Perhaps the name 'build_dir' is too explicitly tied to the implementation I did; suggestions for alternate names would be welcome, along with proposals for what the precise semantic definition should be.

For now, I'm happy to have a directory name included in my target name; that is working fine, save for the dire warnings of future incompatibility. All I'm trying to do here is preserve the current capability in a way which provides more control over how it works to the build system.

[jpakkane]

The problem with requiring separate source directories is that those need to exist before running meson itself, and be populated with meson.build files. That would require a pre-processing step in my build process to generate those directories and add suitable meson.build files.

I don't understand this. If you currently have something like:

src = files(...)

shared_library('foo', src, ...)
shared_library('dir/foo', src, ...)

Then the only change you'd need to do is:

src = files(...)

shared_library('foo', src, ...)
subdir('dir')

and then in the dir directory have a meson.build with this:

shared_library('foo', src, ...)

The result of files() remembers where the files come from and it can be used anywhere. Only the target needs to be defined in the different directory. This is because then the system can guarantee that everything needed to have a directory called dir exists and is properly tracked.

[nirbheek]

I don't understand this.

I explained the architecture in the issue about this. There is no static list of dir values.

[keith-packard]

Jussi Pakkanen <notifications@github.com> writes:

shared_library('foo', src, ...) subdir('dir') ``` and then in the `dir` directory have a `meson.build` with this: ```meson shared_library('dir/foo', src, ...) ```

Could you let me do this without having a subdirectory in the source tree and somehow encoding the call to static_library in the parent instead? That's exactly what I want to do here -- I don't know until configuration time what the names will be as they're generated dynamically using: run_command(meson.get_compiler('c'), '--print-multi-lib').stdout() Requiring actual source directories with the names coming from this command would involve changing the source repository at build time. The patch I submitted places this pseudo-source-directory in the target specification, instead of requiring an actual source directory containing meson.build, but is semantically equivalent. It sounds like there might be some additional build directory structural requirements that this might be violating though?

…

-- -keith

[ePirat]

We have a similar problem for VLC, where we need to have all built VLC modules end up in a specific folder in the build dir, regardless of chosen build dir layout, to be able to hardcode this path into a vlc-static executable that will look in this location for the modules instead of the usual places.

[jpakkane]

Build rules may not specify where they will put their things. They shall adapt to the layout specified by the backend.

[keith-packard]

Build rules may not specify where they will put their things. They shall adapt to the layout specified by the backend.

This is patently false -- build rules do specify where they put their things, but they only get to specify the final path element and may not prepend additional directory names.

All we're asking for here is to allow them to insert additional directory names before the final filename. If meson wants to then take those paths and stick them elsewhere in the build directory, that would be totally fine.

Please reconsider this very unhelpful stance; we've demonstrated numerous projects which need to build multiple results with the same final filename but for which intermediate directory paths are generated at build time. I'd strongly prefer this to my proposed rename patch, #13960, as that requires contortions when using generated C header files during the build.

I'll note that generator already allows the user to define subdirectories within the build directory, however they are restricted to names found within the source tree and cannot be defined at build time.

It's been six years now, and no-one has come up with any solution to work around this limitation, a limitation which is not shared by any other build system.