automoc4 from kdesupport now supported for building KDE

[Brad King]

David Faure wrote:
> On Tuesday 03 June 2008, Brad King wrote:
>> The issue here is that we (cmake devs) view the PATHS argument as a list
>> of last resort paths (e.g. hard-coding c:/Python25), not preferred
>> paths.  There are a whole bunch of user-controlled places that are
>> searched before /usr/lib.
> 
> This assumes that users specify all their lib locations as arguments. It's nice to be able
> to do that, but ideally things should just "work out of the box", that's the whole point
> of that list of paths -- to try and autodetect where the stuff is installed, to save the
> user some work.

The motivation behind our view is that users should be able to set
CMAKE_PREFIX_PATH and have CMake find things there first.  Currently the
only way to override what the NO_DEFAULT_PATH stuff finds is to set the
result variable in the cache by hand for each and every library.  If you
(as a project dev) want to look in a set of default locations on the
users' behalf, they should be added to the search path variables by the
project.  Then none of the find_* commands needs special arguments, only
one call to each is needed, and users can override things easily.

>> If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
>> tell you where to find the library, why do you need to search for it in
>> default paths at all?
> 
> Because those are just hints. Maybe phonon is in the kde install dir, but maybe it has
> been installed into its own prefix instead. In the first case it should be autodetected,
> while in the latter case it's normal that the user has to specify a prefix -- but that doesn't
> work because of NO_DEFAULT_PATH (which is only there so that the autodetection
> prefers KDE4_LIB_INSTALL_DIR over /usr/lib, not to prevent users from setting the right
> path manually!).

Okay, so follow the above advice:

  find_package(FOO REQUIRED)

  # Foo tells me where I might find other stuff.
  list(APPEND CMAKE_PREFIX_PATH ${FOO_INSTALL_PREFIX})

  find_library(BAR_LIBRARY NAMES bar)
  # tada!  BAR_LIBRARY is found under <foo-prefix>/lib

If the user specifies a custom CMAKE_PREFIX_PATH it will override what
FOO says.  In practice the find_library will be in a find script or
something.

>> When CMake 2.6 is required everything should switch to using the
>> export/import feature:
>>
>> http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets
>>
>> along with the full power of find_package and this issue should go away
>> completely.  CMake will then just load a file that tells it exactly
>> where libraries are located (i.e. full paths to the library files).
> 
> ... as long as it finds that file in the first place, so I'm not sure this changes anything, in fact.
> Autodetection wanted when possible, manual setting of own prefix otherwise...

The idea is that that one file is found by find_package, which is
extremely powerful (more powerful than pkgconfig, in fact).  It also
works well on Windows and OS X (with frameworks too).

>>> Is there a way to get "check those paths first, then fallback to the default paths" behavior, without duplicating
>>> all the default paths in the find_library call?
>> Yes, and it's mentioned in the find_library documentation:
>>
>>   find_library(FOO_LIBRARY NAMES foo
>>                PATHS ${PATH1} ${PATH2} ... NO_DEFAULT_PATH)
>>   find_library(FOO_LIBRARY NAMES foo)
> 
> Ah, right, I remember seeing this. It looks ugly and redundant, but ok :-)

We don't really want this done so it's okay if it's ugly.  See above.

-Brad