#42212 resolved the issue for the headers that have tolua_..._open(). Maybe similar solution would work for the rest?
Reply To cazfi
#42212 resolved the issue for the headers that have tolua_..._open(). Maybe similar solution would work for the rest?
Alternatively we could make autotools build to generate those headers to a separate directory that would still be within "the source tree" in that it's distributed with freeciv, but which meson build would not look headers from.
I think that would be more robust solution, but also a lot more involved - so I guess that 3.1.0-beta1 should go by the #42212 route, even if as a temporary solution.
This is a bit of a problem also with git checkouts, but it occurred to me that release tarballs will be even more affected.
With git checkouts, if one does *only* meson based builds, there's no problem. The problems begin when one does both autotools and meson based builds from the same sources. Autotools builds generate some files to the source directory. Meson generates everything properly to the build directory, so it's not even overwriting autotools generated files. However, when both (potentially outdated) autotools generated version and meson generated version are available, meson may end up using autotools generated one from the source directory.
What makes tarball/release case worse than git checkout case is that those autotools generated files are already present in the tarball. So even if user never does autotools build themselves, meson build does not work properly (if some generated file should be regenerated, i.e. , one tries to build modified version)
Targeting to 3.1, but this isn't necessarily a beta1 blocker - meson based builds are experimental in 3.1, after all. Plan is to make official macOS builds from 3.1 with meson, though.