ecm_setup_version (Re: [karchive] /: Show how qmake integration can be done.)

David Faure faure at kde.org
Sun Jan 5 19:54:33 UTC 2014


On Sunday 05 January 2014 20:30:35 Alexander Neundorf wrote:
> (...without looking at the replies) I wouldn't do that, IMO too much "magic"
> going on.
> Why should a function called ecm_setup_version() set variables called
> FRAMEWORK_SOMETHING ?
> "framework" as used in this context means framework as used here in KDE.
> ecm_setup_version() is not KDE specific.

OK, so bad naming - what about it sets
ECM_SETUP_VERSION_MAJOR/MINOR/PATCH/STRING ?
or
PROJECT_VERSION_* ?
or
PACKAGE_VERSION_* ?

ecm_setup_version already talks about something called PACKAGE_VERSION_FILE
so I guess PACKAGE_VERSION_* would make some sense.

Overall it seems to me that the ${VARIABLE_PREFIX}_VERSION_* stuff was mostly 
because we were bundling all the frameworks together in kdelibs. And anyway if 
someone has two frameworks in the same cmake project, each in one subdir, the 
PACKAGE_VERSION_* variables won't clash, each being only available in the 
directory where ecm_setup_version is called, right?

> I'd just hand the version number as argument to ecm_generate_pri_file() and
> then it's easy to read and no magic or confusion involved (...but more
> typing).

That would mean 4 arguments more to the function (I definitely don't want to 
pass 5 0 0 by hand, but instead to pass ${KARCHIVE_VERSION_MAJOR} etc.)
This won't be easy to read, it'll be a very very long function call overall.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5



More information about the Kde-buildsystem mailing list