skipping the kdeinit magic on windows (Re:

[Alexander Neundorf]

On Thursday 10 April 2008, you wrote:
> Alexander Neundorf schrieb:
> > On Tuesday 08 April 2008, Ralf Habacker wrote:
> >> David Faure schrieb:
> >>> On Monday 07 April 2008, Ralf Habacker wrote:
...
> > ---------------------------------------------
> > 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

Yes, but increasing the number of these without _real_ need is no advantage in 
itself.

> kde to have replacements for basic cmake macros because basic cmake
> commands mostly do not fit the need.

This depends on the definition of "mostly".
$ cmake --help-command-list|wc -l
89
So cmake 2.4.6 has 89 built-in commands.
The following KDE macros replace/extend existing cmake commands:
kde4_add_executable()
kde4_add_library()
kde4_add_kdeinit_executable()
kde4_add_unit_test()
kde4_add_plugin()

All these macros create targets.
We have a whole bunch of macros which handle KDE-specific stuff, mostly 
generating code from some files. This is something different, since they 
don't replace existing commands.

kde4_kdeinit_link_libraries() and kde4_kdeinit_install() are new, they would 
be the first macros directly replacing other cmake commands (beside the 
target-generating ones).

Beside that, about 80 commands are not wrapped into KDE versions.

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

Maybe you consider it natural, I as the one who in general designed the 
existing macros don't (see the list above).
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.

> 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

I can't remember the exact patch, but cmake 2.6 is now able to generate 
documentation for custom modules when CMAKE_MODULE_PATH is specified. Is that 
what you mean ?

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

Generating documentation is important, but a different topic.

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

I hope my previous email made it clear that I'm not totally opposed to the 
patch. But until now I don't see *significant* advantages but a few 
disadvantages, whether they are considered significant or not may depend on 
personal opinion.
That builds will break on windows if some non-windows developer just continues 
using the KDE 4.0.x style (which we _must_ continue to support) since it 
works for him is maybe actually not really insignificant. 

Now, your email didn't really help me coming to a conclusion. It was mostly 
a "IMO two new cmake macros are easier than remembering one additional if()" 
and you didn't respond to the other points.

So, I'm still not convinced.

Alex