Flex, Bison, and CMake compatibility

[Alexander Neundorf]

On Saturday 25 June 2011, Nicolas Alvarez wrote:
> Hi,
> 
> I'm trying to change the kdelibs buildsystem to generate Flex and Bison
> parsers at compile time, instead of keeping the generated code in version
> control.
> 
> One problem I'm hitting is compatibility with CMake 2.6. The FindFLEX and
> FindBISON modules were introduced in CMake 2.8. Copying the files into
> kdelibs/cmake/modules still fails because they use
> ${CMAKE_CURRENT_LIST_DIR} to include FindPackageStandardArgs, and that

You can use get_filename_component( ... CMAKE_CURRENT_LIST_FILE .. PATH) to 
get the same. It's just more typing.

> variable was also introduced in CMake 2.8. (note that I don't plan to make
> kdelibs install these two modules; they're just for kdelibs's own use).

I plan to make KDE depend on cmake 2.8.6 later this year, when everything we'd 
like to get into cmake is in cmake (like e.g. automoc)

So by then, we will be able to rely on the new module in cmake.

I'd like to avoid to raise the required version now to 2.8.4, and in 4 months 
to 2.8.6, to avoid trouble for the developers.
 
> The reason it uses CMAKE_CURRENT_LIST_DIR is to workaround an
> incompatibility hell with FindPackageStandardArgs (interesting read):
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4275592a8
> 
> As far as I can tell, we don't have this problem, because the version of

This stuff is in cmake because _we_ (KDE) had the problem.
We had a copy of FindPackageHandleStandardsArgs.cmake from cmake 2.8.0 or so, 
and then in 2.8.3 the version in cmake was extended (in a source compatible 
way), and when using one of the find-modules from cmake which was updated to 
use that new version, the build of KDE broke because that find-module did not 
get the FindPackageHandleStandardArgs.cmake it expected, but ours, which was 
too old for it.

> FindPackageStandardArgs included in kdelibs/cmake/modules is new enough and
> has the "second mode" that FindFLEX and FindBISON use. 

This stuff and t

> So a simple
> INCLUDE(FindPackageHandleStandardArgs) would work, or we could prefix it
> with ${kdelibs_SOURCE_DIR}/cmake/modules/ to be 100% sure.
> 
> 
> A second problem is that kdelibs already has a FindFlex.cmake (note case!)
> which is pretty different, it only looks for the flex executable and sets a
> variable with its path, but it doesn't have its own fancy targets to run
> it. We would have problems in Windows if cmake/modules contains two
> modules with the same name. And yet we can't just delete FindFlex.cmake,
> because it's *installed*, so we'd break kdelibs source compatibility!

We'll break source compatibility once when we move from kdelibs to "KDE 
frameworks".
Until then, we have to get along with it.

Alex