skipping the kdeinit magic on windows (Re:

[Alexander Neundorf]

On Tuesday 08 April 2008, Ralf Habacker wrote:
> David Faure schrieb:
> > On Monday 07 April 2008, Ralf Habacker wrote:
> >> I do not understand some things: There is a complete platform
> >> independent solution which looks nice to the package developer, which
> >> removes the if(...) issues in the CMakeLists.txt for ever

The problem is not the if() itself, but that the code inside the if-branches 
was too complex.

> >> and it is rejected against a low level platform specific solution
> >>
> >> kde4_add_kdeinit_executable( kfmclient NOGUI ${kfmclient_SRCS})
> >> target_link_libraries(kdeinit_kfmclient  ${KDE4_KIO_LIBS} )
> >> install(TARGETS kfmclient ${INSTALL_TARGETS_DEFAULT_ARGS} )
> >> if(NOT WIN32)
> >>    install(TARGETS kdeinit_kfmclient ${INSTALL_TARGETS_DEFAULT_ARGS} )
> >> endif(NOT WIN32)
> >>
> >> which is
> >> - only full understandable by inspecting KDE4Macros.cmake,

The same is even more valid when introducing two new macros.

> >> - forces unix developer to know windows install behavior to setup the
> >> the build system correctly,

No difference here, with two new macros the unix developer must remember that 
he has to use them (otherwise the windows build will break), although it 
works for him also without them using the KDE 4.0 style.

> >> - needs ongoing patch effort of kde windows developer in case linux devs
> >> forgot to think about windows install behavior and

No difference, see above.

> >> - needs patching of an outside tool

To fix eventual forgotten cases, yes.

> >> only to avoid introducing two macros, which are designed to use the
> >> known call sequence(add_... _..link_libraries, __install) ????
> >>
> >> Sorry, please take this not personally, but I do not think that this is
> >> the right way :-P - I believe a build system should make it as much as
> >> easy for package developers and to encapsulate platform issue as much as
> >> possible into some internal macros and if it is required to introduce
> >> new macros then it should be.
> >
> > I agree with Ralf. Let's make it easy and correct, rather than difficult
> > and wrong.
>
> ... and how to proceed ? Should I add those scripts to KDE4Macros.cmake
> or should alex rework his patch or ....?

I'm undecided.

Here's the situation as I see it:

the baseline with cmake is the following:

add_executable(foo ${fooSrcs})
target_link_libraries(foo bar blub)
install(TARGETS foo DESTINATION bin)


I'd like to stay as close as possible to that, so that users/developers don't 
have to learn too much new stuff (this is one of my main goals with the cmake 
stuff for KDE).
With KDE 4.0 we have for kdeinit:

kde4_add_kdeinit_executable(foo ${fooSrcs})
target_link_libraries(kdeinit_foo bar blub)
install(TARGETS foo kdeinit_foo ${DEFAULT_INSTALL_ARGS})

There are some things which are not obvious:
-where does kdeinit_foo come from ?
-why do I have to link libraries against kdeinit_foo instead of foo ?

But at least there is only one kde-specific macro required.

---------------------------------------------
Now with Ralfs approach it will look like:

kde4_add_kdeinit_executable(foo ${fooSrcs})
kde4_kdeinit_link_libraries(foo bar blub)
kde4_kdeinit_install(foo DESTINATION bin)

Pros: 
-code looks simple
-handles everything correctly

Undecided:
-kdeinit_foo is hidden: too much magic ?

Cons:
-two more macros (to remember and to maintain), with plain cmake knowledge you 
don't know what happens
-if some linux developer doesn't use the new style macros, the build will 
break on Windows (he will try to link against kdeinit_foo, which doesn't 
exist anymore)

---------------------------
With my approach:

kde4_add_kdeinit_executable(foo ${fooSrcs})
target_link_libraries(kdeinit_foo bar blub)
install(TARGETS foo ${DEFAULT_INSTALL_ARGS})

if(NOT WIN32)
   install(TARGETS kdeinit_foo ${DEFAULT_INSTALL_ARGS})
endif(NOT WIN32)

Pros:
-no new macros: neither to learn nor to maintain (forever), basically
 unchanged compared to KDE 4.0
-handles everything correctly
-if some linux developer forgets the "if(NOT WIN32)", it will work 
nevertheless also on Windows, the only downside is that on windows a useless 
(but really tiny) static library will be installed

Undecided:
-no change in the level of being cryptic
-not more facts to remember than with Ralfs idea:
   here: don't install kdeinit_foo under windows
   Ralf: use kde4_kdeinit_link_libraries() and kde4_kdeinit_install() instead
         of the plain cmake commands

Con:
-slightly more complicated code
-using the static kdeinit_foo library just as "linking proxy" is not very
 straightfoward

-------------------

So beside style issues, the main difference is that if 
kde4_add_kdeinit_executable() is changed in such a way that under windows no 
library is created anymore, all current cmake kdeinit code _must_ be adapted 
if it should build under Windows, unchanged the build breaks.

I'd put it this way: the kdeinit stuff is somewhat hackish in itself, so we 
may end up with a somewhat hackish solution also in cmake.

Alex