Config files for frameworks

[Stephen Kelly]

Alexander Neundorf wrote:
>> There is no point in keeping cmake files looking exactly as they do now
>> if we can instead remove noisy/redundant information. That is progress.
>> If it was 2006 what would you choose?
> 
> I would prefer if both ways would stay valid and continue to work as they
> do now:
> 
> include_directories(${Foo_INCLUDE_DIRS})
> add_executable(hello main.cpp)
> target_link_libraries(hello ${Foo_LIBRARIES})

All of the 'Foo's have never existed before. No code out there uses 
${KItemmodels_INCLUDE_DIRS}, so no need for compatibility with it.

I still don't think you're making a good argument for setting them - If we 
set them at the beginning we can never remove them. 

Yes, people have to learn that they don't need to do that anymore, but I 
don't think that will be a big problem. I think the porting story will look 
something like this:

* We create a compatibility cmake file containing things like 

 set(KDE4_KDECORE_INCLUDES "")
 set(KDE4_INCLUDES "")
 set(KDE4_KDECORE_LIBS karchive kcoreaddons etc)

* People porting KDE4 code to kf5 will include() that compatibility file and 
rebuild. include_directories(${KDE4_INCLUDES}) will not be an error, but 
will be harmless and useless. target_link_libraries(kfoo 
${KDE4_KDECORE_LIBS}) will actually link to the new frameworks broken out 
from the kdecore library, and will make sure their corresponding include 
directories are available.

It won't work 100%, but it will get people started.

* People remove their include() of the compatibility file (if they want to 
be 'clean'), replace variables with their expansion except for what they 
don't use (eg, don't replace ${KDE4_KDECORE_LIBS} with karchive if karchive 
is not used), and remove the include_directories calls where not needed. 

Note also that we can make all this include_directories-not-needed stuff 
possible in KDE4, which will make porting easier too (less noise, less 
problems in an area which people always get wrong - Kevin just made a 'fix 
compile' commit which resulted from the include_directories non-
automaticness 
http://quickgit.kde.org/?p=kdelibs.git&a=commit&h=97bd7772dcc7f034f1f8bc1935bd93c3246057ad).

I think not having to change all target_link_libraries() to 
target_use_targets() is a good thing. 

And I volunteer to take care of anyone who comes to the mailing list 
confused and worried about not having to use include_directories() anymore 
:).

> 
> as well as
> 
> add_executable(hello main.cpp)
> target_use_targets(hello Foo::FooLibrary)
> 
> 
> This would make obvious what's going on, and not change the behaviour of
> an existing command.
> The second one might even warn if the used target doesn't have include
> directories set etc.
> (I haven't actually checked your implementation, sorry if this is already
> the case)

There is no warning in that case currently. That might be a good idea.

>> The second reason is that any files which happen to be in the directory,
>> but are undocumented, are internal, and not for downstreams to include().
> 
> It's not like this would be a fixed, written down rule.
> Even if it was, not everybody might know or follow that rule.
> I don't think providing this PREFIX variable or not is a significant
> issue.

I think it is a significant issue because it's a maintenance burden

Also, anyone new who comes along and tries to make a framework will be told 
they also have to populate a variable of a similar name even though it is 
not used or useful, and even though it is just a duplicate of a variable 
that CMake already creates (the _DIR variable) - eh, confusing, don't you 
think?

Lets please not create loads of INSTALL_PREFIX variables, and just create a 
variable pre file.

Thanks,

Steve.