overriding CMAKE_MODULE_PATH

[Michael Jansen]

> Did you contact kitware, or is this a 'your' problem?
> 

No clue. I send the email three times. I guess its in the moderation
queue or spam folder. I am subscribed to the list. But i gave up on that
attempt. I hope someone from kitware is on this list

> I thought distro's have switched to lib/ for 64 and 32 bit (depending on
> which is the system-arch) and lib32 for the 32-bit compat libs in a
> 64bit System... Anyway, the above is something you should be taking to
> cmake people, obviously lib64 should be searched first if the compiler
> is 64bit. As far as I can see the problematic case would be having
> development-stuff installed for the 32bit version of qjson and no 64bit
> version or having both and the 32bit version is found and I wonder how
> realistic that is (I don't think its possible on Debian at least,
> because only some basic libs are provided as 32bit version on a 64 bit
> install).

I have no idea if lib32 is even supported with cmake. There is no
FIND_LIBRARY_USE_LIB32_PATH as far as i can see.

On opensuse it is possible to run 32bit and 64bit development in
parallel. For each 64bit package is a 32bit version and a 32bit-devel
version too.

>> And now to the problem. A find_package( qjson ) will work for some and
>> not for others. And that is the same for all packages using the all
>> lowercase name for their config.cmake files.
>>
>> If i am right i would consider the all lowercase names harmful.
> 
> Yes in that its much more forgiving than the camel-case stuff when it
> comes to people being sloppy with their find_package call (or doing
> mistakes). Nonetheless if the FindQJson.cmake module is only a thin
> wrapper around the config-mode version to give some nice messages all
> people still will get the same behaviour.

NO THEY WON'T. A 64bit user will pick up 32 bit packages under certain
circumstances. If the FindXYZ*.cmake package is implemented.

>> A project like QJSON that tries to install a FindQJSON.cmake (however
>> useful that is) misleads it's users therefore. They perhaps only set
>> CMAKE_PREFIX_PATH, add a find_package(QJSON) and run cmake.
> 
> That would be the error, they shouldn't set CMAKE_PREFIX_PATH in the
> first place, that variable is _purely_ meant for users to set during
> cmake-invocation or in the cache.

This is from the users perspective. The USER sets CMAKE_PREFIX_PATH. The
config parts of qjsons installation are found (*Config.cmake), the
module part not (FindXYZ*.cmake).

Which i find confusing and is not the behaviour i would expect. And
let's add to that. install(EXPORT) installs into CMAKE_INSTALL_PREFIX.
Why shouldn't the FindXYZ*.cmake file go there too? KDE install it's own
FindXYZ*.cmake files. Why should other projects not do it?

We currently try(tried?) to convince PolicyKit and DBus to allow
installing configuration files into different prefixes. Why don't we
expect the same from cmake?

The current behaviour is inconsistent.

>> It works. Sometimes. But only using the config mode. Because they
>> would have to set CMAKE_MODULE_PATH too. And only as long as they
>> don't install some 32-bit development version of qjson.

And this is the explanation.

> See above, I wonder how realistic it is to have 32-bit development stuff
> on a 64bit System in the system prefix. 

Pretty realistic. I have some not really useful stuff 32bit devel stuff
installed myself and then think of someone trying to build both 32 and
64 bit packages for distribution.

>> This is all probably a theoritical problem with not much practical
>> relevance but i thought i would inquire anyway.
> 
> Exactly, so lets keep to practical problems like the one this thread is
> about.

Always ready to suppress or end a discussion from the start? Aren't you?
(This is not the first time).

This was a question. I think it is realistic. And people start to use
the Config Mode without providing a FindXYZ*.cmake file. So it is even
more important. Some of them are from kde. I had a lengthy discussion on
irc with someone doing that.

And given cmakes annoying habbit to not distuinguish in it's error
message between finding no FindXYZ*.cmake file or finding an version
imcompatible package with the FindXYZ*.cmake file i consider it even
more annoying that CMAKE_MODULE_PATH does not behave according ALL OTHER
cmake paths in that it automatically adds corresponding directories from
CMAKE_PREFIX_PATH.

Mike