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, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
Kde-buildsystem mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-buildsystem
