Hi, On 2022-06-02 13:08:49 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > I'm not quite sure what the proper behaviour is when doing an out-of-tree > > build with meson (all builds are out-of-tree), with a pre-existing flex / > > bison output in the source tree that is out of date. > > Definitely sounds like a gotcha. > > On the one hand, there's been some discussion already of removing all > derived files from tarballs and just insisting that users provide all > needed tools when building from source. If we did that, it could be > sufficient for the meson build to check that no such files are present > in the source tree. (Checking a couple of them would be enough, likely.)
There already is a check for pg_config.h, so the most obvious source of this is addressed. Just didn't think about the files that make clean doesn't remove :/. > On the other hand, I'm not sure that I want such a change to be forced > by a toolchain change. It definitely seems a bit contrary to the plan > we'd formed of allowing meson and make-based builds to coexist for > a few years, because we'd be breaking at least some make-based build > processes. Agreed. I think it'd be pretty reasonable to not include flex / bison output. They're not hard to acquire. The docs are perhaps another story. I think it might be fine to say that make reallyclean (*) is required if there's some conflicting in-source tree file? > Could we have the meson build check that, say, if gram.c exists it > is newer than gram.y? Or get it to ignore an in-tree gram.c? I suspect the problem with ignoring is gram.h, that's probably a bit harder to ignore. Right now I'm leaning towards either always erroring out if there's bison/flex output in the source tree (with a hint towards make reallyclean(*)), or erroring out if they're out of date (again with a hint towards reallyclean)? Alternatively we could just remove the generated .c/h files from the source dir, as a part of regenerating them in the build dir? But I like the idea of the source dir being readonly outside of explicit targets modifying sources (e.g. update-unicode or such). Greetings, Andres Freund (*) do we really not have a target that removes bison / flex output?