extra-cmake-modules: ECM_VERSION() macro

[Alexander Neundorf]

On Monday 12 December 2011, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Wednesday 30 November 2011, Alexander Neundorf wrote:
> >> On Wednesday 30 November 2011, Alexander Neundorf wrote:
> >> > On Wednesday 30 November 2011, Stephen Kelly wrote:
> >> > > Alexander Neundorf wrote:
> >> > > > Hi,
> >> > > > 
> >> > > > in extra-cmake-modules we have a file ECMVersion.cmake, which
> >> > > > contains a macro ecm_version().
> >> > > > 
> >> > > > This macro is not documented, and "ecm_version()" is not a good
> >> > > > name for a function (or macro), since it doesn't contain a verb.
> >> > > > 
> >> > > > How is this macro intended to be used ?
> >> > > > Is it intended to be "public" or is it used only internally ?
> >> > > > 
> >> > > > We have to be careful, once we ship a release we must keep
> >> > > > compatibility.
> >> > > > 
> >> > > > Alex
> >> > > 
> >> > > Each framework uses it in the frameworks branch. The idea is to have
> >> > > a compact way to set the version which could be updated by scripty
> >> > > (as there may be many more places where the version needs to be
> >> > > updated on release)
> >> > 
> >> > Can you please add documentation to it ?
> >> > How about changing the name to ecm_declare_version_variables() or
> >> > something like that ?
> >> > ecm_declare_version(), ecm_set_version_variables(), ...
> >> > It really should have a verb in it.
> >> 
> >> How about
> >> ecm_set_version_variables( [PREFIX prefix] VERSION x y z) ?
> > 
> > I added a
> > 
> > ecm_set_version_variables( <prefix> <major> <minor> <patch>)
> 
> Thanks, sorry I didn't get around to doing this.
> 
> > to extra-cmake-modules, including documentation.
> > As prefix a project-specific prefix should be used, e.g. in kio "KIO"
> > would be a good choice, which would give KIO_VERSION_MAJOR etc.
> > 
> > If we agree on this, I'll put a deprecation message in ECMVersion.cmake
> > and remove it new year or so.
> 
> If we port away from it we can just remove it. No need to deprecate and do
> a delayed removal.

Ok.
 
> > Some doubts I still have:
> > * we set FOO_VERSION_MAJOR, while cmake defines for itself
> > CMAKE_MAJOR_VERSION, i.e. just the other way round.
> 
> I might have been following KDE convention there. I don't mind changing it
> for consistency with CMake.

Yes. I just noticed that it is just the other way round, but did not yet look 
around what version might be considered "standard".
We might also remove the "_STRING" from FOO_VERSION_STRING and just name is 
FOO_VERSION. I think this is actual more standard.
 
> > * the prefix could be made optional, and if none is given, the name of
> > the current project would be used, i.e. if no name has been set
> > PROJECT_MAJOR_VERSION etc.
> 
> Sure.

Now, while thinking about it, this would basically mean using 
CMakeParseArguments.cmake, which is ok, but which turns the trivial 5-lines 
macro into an actual function, which would be more complicated than simply 
writing those 5 lines down, for only little added value.
 
> > Comments ?
> 
> I'm happy enough with the proposed changes. 


> I think we'll need to think
> harder about the way frameworks are built with ECMQtFramework anyway. I
> wrote that partially experimentally looking for feedback, but there's some
> hacks in it which I don't really like (a lot of stuff with the project
> name).

Ok.
I had a closer look at it in the last days and wanted to get back to it in the 
next days.
I don't really like the general approach.
With the cmake stuff in kde4 I tried to make it as little magic as possible, 
i.e. it should be always visible what is going on.
Including ECMQtFramework.cmake does several things invisible in the 
background, so I would assume that the average developer does not know what 
happens or understands why and how it happens.
It's a bit like
include(DoAllTheMagic)

I tried to avoid that as much as possible with the macros for kde4.

I think it is important not to hide the Config.cmake.in files from the 
developers. They need to understand what they are good for, and that they 
should be used to carry any necessary information to their library users. So 
using a standard FooConfig.cmake.in is not a good idea.

Also, I think hiding the install(EXPORT ...) is not good, because the 
developers have to deal with expoprting targets. They need to do that in their 
install(TARGETS ....) calls. If the install(EXPORT ... ) is hidden, it will be 
harder to understand what the EXPORT argument in install(TARGETS ...) is good 
for.

Developers should also know where those configured Config.cmake files are 
installed to, so they can understand what cmake wants to tell them if it 
complains that it could not import some targets, or something like this.

It also feels a bit like "this is what we had in kdelibs, but now we don't 
have kdelibs anymore, so let's put it in e-c-m", although this is very KDE-
specific (or specific for our group of developers) behaviour.

We should think again whether we really want to set CMAKE_CXX_COMPILE_FLAGS. 
This is in general not good style, we should at most set something like 
KF5_CXX_COMPILE_FLAGS, and leave it to the user whether he wants to use those 
flags or not.

If we put this in e-c-m, I think we should give it a name including "KDE" and 
not pretend it is something generic.

I think all the settings, like compiler flags etc., could go into a file like 
KF5Defaults.cmake, which can be included or not.
What is left then are mostly the configure_file() and install() commands, and 
as hinted above, I actually prefer to have them not hidden.

So, where should KF5Defaults.cmake go ?
Into e-c-m ?
Its contents depends on what we, the KDE guys, decide what is good for KDE. So 
it would belong into some KDE-specific package (which e-c-m is not).

Before it was kdelibs, but what is it now ?
Is it some "meta-kdelibs" package, which mostly consists of buildsystem stuff, 
and which should be installed before building anything from KF5 ?

Alex