Modified build system for itemmodels

[Alexander Neundorf]

On Sunday 06 May 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> >> kf5_do_common_stuff() # TODO: Get better name
> > 
> > Where should this macro come from ?
> > Should this be expanded from @PACKAGE_INIT@ or from an included file ?
> > From an included file would be bad, this would add compatibility issues
> > for the included file.
> 
> You mean if it's supplied by ecm or cmake, that different versions might do
> different things, and this depends on the version of CMake/ecm that the
> user of that config file is using?

Yes.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2833/focus=2834

> How is that different to a macros file using ParseArguments or a Config
> file using set_package_properties from FeatureSummary, as we expect Config
> files to do?

Good question.
I'd very much expect FeatureSummary.cmake to be used in Find-modules.
Should they be used in Config.cmake files ?
The information can contain:
* URL - where do I get this package
* a DESCRIPTION - what is this package
* a TYPE of the requirement
* the PURPOSE in the project

TYPE and PURPOSE belong in the using project.
URL and DESCRIPTION belong to the used project, so they are candidates for 
being set in the Config.cmake file.
But there are two downsides of setting them in the Config file:
- the information where to get the package is not present when the package is 
not present
- the Config file has to, as you mentioned, include() FeatureSummary.cmake, 
which drags in compatibility issues.

I think having trivial FindFoo.cmake files even for projects which install 
Config files is a good thing.
They can set such information, they can do stuff, like search dependencies, 
they can provide documentation and they make it easy for users to check how a 
package is searched.

So, if possible, we should not include more external files than strictly 
necessary into Config files.

We are the first project which starts to use Config files extensively, and 
where those installed libraries also have non-trivial dependencies.
So it's clear that we see many issues the first time.
 
> >> It also sort of turns into a macro with a lot of API. How would I define
> >> macros in my Config file or include() macros file, or do any of the
> >> other powerful things that Config files allow me to do?
> > 
> > Slightly modified:
> > 
> > ecm_write_basic_config_file(${CMAKE_BINARY_DIR}/FooConfig.cmake
> > 
> >                   PATH_VARS     FOO_INSTALL_DIR FOO_INCLUDE_DIR
> >                   FOO_DATA_DIR
> >                   OTHER_VARS    FOO_WITH_Bat FOO_WITH_Blub FOO_LIBRARIES
> >                   FILES_TO_INCLUDE
> >                   FooLibraryTargets.cmake;FooMacros.cmake
> >                   EXTRA_CONFIG_STRING "#something more for the Config
> >                   file" )
> > 
> > You can put the macros into FooMacros.cmake, which would be included by
> > the Config.cmake file, or you could put them into EXTRA_CONFIG_STRING.
> 
> The list of things that would have to go into such a macro would keep
> growing and growing.
> 
> It would need to be told what its (public) dependencies are, because they
> should be found and their variables integrated into its own variables:
> 
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2574

Won't propagating the libraries and include dirs to use be done via your work 
on target_use_package() ?
 
> Then there's optional dependencies too, which would have to be found, and
> which might have an effect on how the variables are populated... You can't
> stuff everything into a macro like that. It becomes very unwieldy and I
> don't think it's flexible enough.

It's name contains "basic", I think it is good enough for "basic" Config.cmake 
files.
Also, with the feature to be able to include() additional files into the 
Config.cmake file you can more or less do whatever you want.

As I said, you can put a lot of stuff into Config.cmake files, so the 
developer has to understand them and actually write them.

So your main point is to avoid repeating the trivial parts ?

We have them now because we decided to split kdelibs into multiple 
repositories.

Also we decided to try to avoid using stuff which is not in cmake itself.
Now adding trivial stuff to e-c-m with the only purpose to make the life of 
the KDE buildsystem maintainers easier, defeats this.

Please post a proposal for what you want to do with the version stuff.
I really want to get rid of this ASAP:

macro(ecm_version _major _minor _patch)
  set(ECM_VERSION_MAJOR ${_major})
  set(ECM_VERSION_MINOR ${_minor})
  set(ECM_VERSION_PATCH ${_patch})
  set(ECM_SOVERSION ${_major})
  set(ECM_VERSION_STRING
    "${ECM_VERSION_MAJOR}.${ECM_VERSION_MINOR}.${ECM_VERSION_PATCH}")
endmacro()

and I want to actually start working on kf5 before Akademy.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120506/789cf872/attachment-0001.html>