Alexander Neundorf schrieb:
> 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
>
to build kde applications it is required for developers to know several
macros only available in the kde namespace - in fact it is natural for
kde to have replacements for basic cmake macros because basic cmake
commands mostly do not fit the need.
One example is the add_executable cmake command which uses a 'win32'
term to make the application a gui application, if this argument is not
used a console application will be created. On MAC/OSX
add_executable(<target> [WIN32] <sources>)
in the kde namespace there is a similar command with a different
behavior - first without the second argument the default is to create a
gui application and console applications are created when the term
'NOGUI' is used
kde4_add_executable(<target> [NOGUI] <sources>)
- in fact this defines a platform independent way for selecting gui/non
gui applications and implies that for kde developing using
add_executable is a no go because it is platform depending.
I learn from this that when developing kde application i should use kde4
macros at first and only in the rare case where no such macro is there a
basic cmake should be used - this is the approach we do in kde software
development when we derive classes. This means it would be natural to
have for example a kde4_install macro and others.
cmake should also now be able to print a list of kde cmake modules and
the macros they contain in the project which is currently builded
because some month ago I posted a related cmake patch to alex which was
implemented in the cmake --help-module-list, which listed all kde
modules in the project becide the basic cmake commands and cmake
--help-module which lists all macros and it's documentation of the
related cmake module.
> -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.
>
The question is if there is a way to implement it easy and correct ?
Ralf