Fix tagtbl.C placement in build dir

[dmnks]

The COMMAND for tagtbl.C generation dumps the file in the top-level build directory whereas the OUTPUT is specified in the current (lib/) directory. This leads to unnecessary relinking of all the libraries on each make invocation because OUTPUT is always missing.

Fix this by outputting the file in the current directory where OUTPUT can find it.

No functional change, just makes rebuilds quicker.

[pmatilai]

Ooh, good spotting! I remember there was some "reason" for doing it the way it was, but this would've been added during the first weeks of stumbling in the dark with cmake. So it probably was due to some other mistake, misunderstanding or such.

[dmnks]

Heh, sure 😄

Actually, the output location was only changed in the recent commit 1c98b67 so it was more like just a forgotten entry in target_include_directories(librpm PRIVATE ...) where it didn't include the current build dir. So this commit was basically just a fixup adding that 😄

[pmatilai]

Oh. So I'm misremembering something else related to tagtbl.C from the early days then. I wonder wtf I changed it in 1c98b67 for, doesn't seem to make any sense at all 😳

[dmnks]

We actually include the top-level build directory in the top-level CMakeLists file, it even says # generated sources in a comment. So that could've been the impulse for you to output it there so that you didn't need to add the current build dir into the new include list in lib/CMakeLists.txt, I suppose.

At first, I thought the fix would be just to use OUTPUT ${CMAKE_BINARY_DIR}/tagtbl.C, however that turned out wrong because we link compile librpm against from that file (further up) and since it doesn't exist in the source dir, cmake tries to find it in the binary dir, and failing that, tries to find a target that builds it - which is this one. So putting a prefix such as ${CMAKE_BINARY_DIR} to it would cause cmake to not find it, and fail 😄