Best practices with public generated headers

[Rafael Avila de Espindola]

I have been playing around with meson and as an exercise I am trying to
use it to build seastar (https://github.com/scylladb/seastar).

An interesting issue is how to handle generated headers that are public
(should be installed) but are also used internally.

The desire is that a library foo providing gen.h will install it in
include/foo/gen.h and includes, both in the library foo and externally,
will be

#include "foo/gen.h"

From the meson manual my first try was to use a generator object with
preserve_path_from. This solves the relative path issue, but the
produced header is not really part of the library. Any target with a
dependency on foo would have to list the header as one of its sources.

As the manual points out, anything that should be installed should use
custom_target. Using that makes the generated header part of the
dependency, but it has no preserve_path_from equivalent.

The best solution I found is to generate the headers from
include/foo/meson.build. I have a small demo in

https://gitlab.com/rafael.espindola/meson-public-gen-header

Is that the best way to do it? Is not having something like
preserve_path_from in custom_target intentional?

Also, what is the use case for the generator's behavior of recreating
the output for each target and not being part of a library when included
in its sources?

Thanks,
Rafael

[Noah Watkins]

Hey Rafael,

I have a Seastar Meson build and my approach was to move the ragel files to where the headers would be generated:

   https://github.com/dotnwat/seastar/blob/meson/include/seastar/http/meson.build

It's a bit less flexible than CMake where the output can be generated, by the constraints are now growing on me. If you really need an escape hatch then building a small wrapper and invoking it is an option. I've also seen some more elaborate workarounds in github discussions.