[Development] [cmake-developers] Installing Qt5Config.cmake from the Qt repo?

[Alexander Neundorf]

On Thursday 03 November 2011, Oswald Buddenhagen wrote:
> On 11/03/11 19:44, ext Alexander Neundorf wrote:
> > On Wednesday 02 November 2011, Oswald Buddenhagen wrote:
> >> and neither does foo/bar/libbaz.so.
> > 
> > Why ?
> 
> it's not abstract. 

This is in itself neither an advantage nor a problem.
The whole world is not abstract. Still it works.
It would make the discussion easier if you could try to explain your thoughts, 
instead of just throwing in a few words.

> it does in no way refer to the packages it depends on
> in turn. you can only make cumulative command lines.

E.g. the KDE libraries state which Qt libraries they depend on, by using the 
target names of the Qt libraries. So these targets must be provided by cmake 
at configure time. They can come too from Config.cmake files.

So, at cmake-time of an application which uses a KDE library, Qt is searched, 
the Qt libraries are created as imported targets, and they can have cmake-time 
dependencies.
If the xml-file simply states the full (or relative) paths to the libraries it 
depends on, this is not possible.
I guess that's the point you want to make ?

Can that be solved ?

CMake does (see above). Can we bring that into general purpose config-files ? 
Well, why shouldn't it be possible ?
What I posted initially was not a fully worked out solution, it was just a 1 
minute rough sketch of the idea.

E.g. such a depended on library could alternatively not be named via its path, 
but (as in cmake) via its "name", which has to be found in another such xml 
file. If it's a library which does not install such a file (i.e. currently, 
all), then it will be the path. 
 
> >> you need abstract dependencies, but that
> >> depends on the build/packaging system again.
> >> 
> >>>> then, how do you define "build
> >>>> configuration" in a build system agnostic way? zero chance.
> >>> 
> >>> At least for Windows it should be clear. There are debug and non-debug
> >>> builds, which are AFAIK relatively clear separated.
> >> 
> >> yes, and release_with_debuginfo, and custom and whatever.
> > 
> > I don't see a problem there.
> 
> well, i do. lumping together two types of release builds into an
> arbitrary "release" category doesn't really cut it.

This is not a new issue. It also exists when using some cmake-based project 
from another cmake-based project. I have no idea what configuration exactly I 
want when I link e.g. against IGSTK.
AFAIK the most important thing is that under Windows you can separate between 
debug builds (which need to link against the debug version of the ... what's 
the name... what is libc under UNIX, and in not-debug versions against the 
not-debug version of that library.
Everything else is unclear anyway.

Alex