skipping the kdeinit magic on windows (Re:

[David Faure]

On Thursday 10 April 2008, Alexander Neundorf wrote:
> Another of my design goals beside staying close to plain cmake syntax was not 
> to add too much hidden magic. This includes not to create macros which do 
> something simple, but only add macros where it would be to much to require 
> this from every developer.
> Adding an if() is not requiring very much, since even if it is forgotten 
> *nothing* breaks on windows.

Think of it as you think of API/application design.
If every user of QLineEdit was *required* to write something like
 if (str.isEmpty())
    myLineEdit.clear();
 else
    myLineEdit.setText(str);
because str wouldn't accept an empty string -- just a fake example --,
then you would say: this is bad API, it requires every user of the setText method
to add an if().

If we couldn't change this in Qt, what would we do? We would add another layer:
in KLineEdit we would write a method that does the above, and all the KDE code
would use that method. And if one day Qt changed, we would have a single place to change.

End of analogy.
Why do I think kde4_kdeinit_install is good? Because one day we might say 
"oh well, with the progress made in binutils, kdeinit modules don't bring any advantage
anymore, let's get rid of them". If we use kde4_kdeinit_link_libraries+kde4_kdeinit_install,
then we won't have to change all the CMakeLists files in KDE, we will only have to change
the definition of those macros. It's all about putting all the logic into one shared layer
instead of spreading the exact same logic all over KDE.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).