Config files for frameworks (Was: KArchive for Qt4)

Stephen Kelly steveire at gmail.com
Tue Dec 4 08:13:56 UTC 2012


Alexander Neundorf wrote:
> I still think it is not a good idea that
> 
> target_link_libraries(foo KF5::widgetsaddons)
> 
> also sets include dirs for the target foo.

> Should I discuss that again on cmake-devel ?

It would seem more appropriate than here, but I think it's already decided.

> 
>> 4) Also on the topic of naming things correctly, kwidgetsaddons_LIBRARY
>> should be kwidgetsaddons_LIBRARIES,
> 
> Yes, I am aware of that, and wanted to change that for all at once.

You mean after committing it as *_LIBRARY everywhere, you want to change it 
all to *_LIBRARIES later? Why not just start with *_LIBRARIES so it doesn't 
have to be change later, or am I missing something?

> 
>> but actually it shouldn't exist at all
>> because users should use the imported target directly instead as I wrote
>> above, instead of using the variable.
> 
> I'm not sold on this.
> When reading a CMakeLists.txt, I see
> 
> find_package(Foo)
> 
> and then I expect to be able to use
> include_directories(${FOO_INCLUDE_DIRS})
> ...
> target_link_libraries(hello ${${FOO_LIBRARIES})

Note that you're not using exact-case in those variables, which I think is 
ill advised anyway.

> Retraining all our users that using include_directories() is wrong doesn't
> sound good to me.

I think re-training is the cost of simplicity, and it's worth it.

You only expect to have to use include_directories() because you have always 
had to. Soon you won't have to. In the future, people using KF5 will never 
have had to.

>> Additionally, you're setting that
>> variable to KDE4__kwidgetsaddons, which we'll only have to rename by hand
>> later.
> 
> I am aware of that. This was to keep one of those libs compatible with
> FindKDE4Internal.cmake, I think threadweaver.
> This is something which can be easily patched with a script.
> 
> 
>> 5) I also see no need for the kwidgetsaddons_INSTALL_PREFIX variable.
> 
> In some cases it is necessary, if the user wants/needs to access
> additional files provided by the package.

If there are additional files provided by the package then we need to 
provide a variable for each of those files, eg

 set(Foo_ExtraMacros "${CMAKE_CURRENT_LIST_DIR}/FooExtraMacros.cmake")

and document that variable. We shouldn't expect users to dig into our 
internals like that, nor should we encourage it. 

If a file is not documented and has no associated variable, then it is fully 
internal and likely to be changed in non-backward-compatibile ways or 
removed entirely.

Besides, cmake already sets Foo_DIR to the location that the Config file was 
found in.

> It also shouldn't hurt.

It hurts because it is more for us to maintain in 20+ files which is not 
needed or useful.

Let's not add a variable like that to all Config files please. For one thing 
you are adding it to places which certainly don't need it (as they have no 
extra files), and for another it is bad API.

>> The tier1 Config files (after CMake 2.8.11) should only contain this:
>> 
>>  set(kwidgetsaddons_VERSION_MAJOR "@KWIDGETSADDONS_VERSION_MAJOR@")
>>  set(kwidgetsaddons_VERSION_MINOR "@KWIDGETSADDONS_VERSION_MINOR@")
>>  set(kwidgetsaddons_VERSION_PATCH "@KWIDGETSADDONS_VERSION_PATCH@")
>> 
>>  if (NOT TARGET KF5::widgetsaddons) # See item 1.
>>    include("${CMAKE_CURRENT_LIST_DIR}/kwidgetsaddonsTargets.cmake")
>>  endif()
>> 
>>  include(FooMacros.cmake) # As required.
>> 
>> The tier2 and higher config files need also to find_package their
>> dependencies.
>> 
>> If you think anything else is needed (apart from for compatibility
>> variables, which we can provide separately - there is no need for
>> compatibility variables for kwidgetaddons as it has not existed before),
>> then please let me know and we can make sure that it can be done with
>> IMPORTED targets instead.
> 
> The libraries may have to provide information about supported optional
> features, but these are typically simple variables, not references to
> files etc.

Let's deal with situations like that as they come up. Do you know of any 
specific examples?

Thanks,

Steve.




More information about the Kde-frameworks-devel mailing list