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.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
