Wrapping a project that has includes directory different than installed

[dotnwat]

I'm working on building a .wrap file for a project that stores its public headers in a directory that is not the same as where it is normally installed as a system package. This is making it challenging to support dependency fallback.

For example, a project with some headers in a directory somedir:

project/
   somedir/*.h

installs these headers into a {prefix}/include/project/*.h. On systems where project is installed via system packages code will use #include <project/header.h> as expected. However, when using the project as a Meson wrap, I have not yet been able to figure out how to handle this situation.

I've had to choose between:

1. changing all the include paths in the application (breaks builds using system packages)
2. replicate all the headers using patch_directory into a new folder structure (copying KLOCs)

Is there a way to address this situation using Meson / an example of project that deal with this? The libupnp wrap in WrapDB seems to have a similar situation, an indeed, when testing it out the header locations don't match what upnp project documentation / examples would suggest should be used.

[eli-schwartz]

The best fix would be if upstream aligned the source tree layout to the "real" header paths.

The only other solution is that somehow, the files MUST be moved during the build, because the compiler itself needs to have a disk location with the right structure and there is no getting around this.

Typically, wraps would perform that move by using configure_file(input: '../foo.h', output: 'foo.h', copy: true) to perform the copy at configure time. There are a couple that do this. Check the WrapDB repository for files which contain the reference include-workaround-meson.

[dotnwat]

Again, thank you for a quick response that solve the problem. I wasn't expecting a configure-time workaround or else I may have found the example. This solved the issue.

The best fix would be if upstream aligned the source tree layout to the "real" header paths.

Indeed. And for several projects that we maintain forks of, this is a light weight change we can make to keep the meson build clean at the expense of a small chore-style git to move some files around. Definitely not feasible for some projects, so this is a nice workaround.