overriding CMAKE_MODULE_PATH

[Andreas Pakulat]

On 16.08.10 12:06:35, Michael Jansen wrote:
> > 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.

Interesting, I wasn't aware of that.
 
> >> 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.

Not only with Find, also in plain config mode I think.

> >> 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).

Well, thats actually the most unproblematic case from the users
perspective. Because for the user the only important thing is that the
module is found so he can build the app using it and that its the right
module. Of course if its the one for the wrong arch he's going to get angry
as soon as something tries to compile/link against it :)

> 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?

Yes and much too many are installed. The only cases where they are
installed (or should be) is when multiple KDE modules are using them. And
they're installed purely for KDE modules, other non-kde apps shouldn't be
using the installed ones (as that would basically mean they depend on kde)
but either copy them or simply try to upstream them to cmake. Ideally we'd
have only FindKDE4Internal.cmake in kdelibs and everything else would be
either config-mode or in cmake itself or both.

> 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?

This is something thats basically off-topic on this list, you have to take
this to the cmake people (simply file a bugreport, they do discussions in
those too).

> The current behaviour is inconsistent.

Agreed, in particular in the case of multi-arch-development.

> > 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.

Well, personally I'd use a chroot or something for building packages so I
get clean packages built (dependency wise). Anyway, I apparently wasn't
aware of the fact this is doable in other distro's.

> >> 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).

See above, obviously my information was lacking and hence I drew the wrong
conclusion of '32bit devel in 64bit system is not really happening out
there'. 

> This was a question. I think it is realistic.

Now you're contradicting yourself ;)
,----
| This is all probably a theoritical problem with not much practical
| relevance but i thought i would inquire anyway.
`----

> 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.

As I said elsewhere in the thread the module providing libs only should
install a XXXConfig file (or -config), all projects using it need the
FindXYZ.cmake (or not if they're ok with badly written error messages).

Andreas

-- 
You need more time; and you probably always will.