skipping the kdeinit magic on windows (Re:

[Alexander Neundorf]

On Friday 11 April 2008, David Faure wrote:
> 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". 

Strictly speaking we can't do this, it would break source compatibility.
KDE 4.0 has been released, and there kde4_add_kdeinit_executable(kfoo) creates 
a target kdeinit_kfoo, which is referenced in the CMakeLists.txt.

This must not change under Linux/UNIX/BSD.

If the kdeinit_kfoo library suddenly wouldn't exist anymore, sources which use 
that wouldn't build anymore.

I am not sure whether not creating kdeinit_kfoo under Windows would be also a 
source incompatibility. I mean, if somebody continues to use the old style, 
it will work under UNIX, but not under Windows.
So one could argue that the new style is a new feature which makes the 
software portable to Windows.
But one could also argue that the new style is basically a source 
incompatibility since what was the official usage in KDE 4.0 is deprecated 
starting with 4.1, since it breaks the build on some platforms.

Your analogy is a convenience function, and this would be a convenience macro. 
Until now we have only (mostly) macros in KDE4Macros.cmake which 
implement "hard" stuff, adding a macro whose purpose is to avoid one if (with 
a simple condition) would go against this, especially considering that I 
don't see *significant* advantages and it also has some disadvantages (see 
above).

> 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. 

I wouldn't like that. If at some point we would decide that kfoo doesn't have 
to be a kdeinit app anymore, this should be done by changing it from 
kde4_add_kdeinit_executable() to kde4_add_executable().
If kde4_add_kdeinit_executable() suddenly doesn't create kdeinit executables 
anymore I would consider this a hack.

> It's all about putting all the logic into one
> shared layer instead of spreading the exact same logic all over KDE.

I don't agree here.
Some logic is spread all over KDE, both in the sources as well as in the build 
files, and I really don't want to do more magic than absolutely required in 
the cmake stuff.

I'll modify the macro so that the syntax doesn't change and no changes in the 
CMakeLists.txt are required, but that it will create regular executables 
under Windows, with icons and all that.

Alex