[CMake] cmake integration

[Pavel Volkovitskiy]

Brandon J. Van Every wrote:
> Pavel Volkovitskiy wrote:
>>
>>
>> It's not my CMakeList.txt, i use sim-im as example of program with 
>> cmake based buildsystem
>> CMakeList.txt (from sim-im sources) always checks for ASPELL but 
>> doesn't uses it if USE_KDE=TRUE
>>
>> I want to know if this common practice (find everything even if you 
>> don't need it) or if this CMakeList.txt has bugs
>> (ie it shouldn't check for aspell if it's not going to be used)
>
> CMake doesn't search for anything unless the programmer says so.  So 
> it's not like Automake in that regard; you're never going to be 
> looking for hordes of useless stuff, unless the programmer actually 
> wanted to do that.  When the programmer wants to find something, the 
> following paradigm is common:
>
> FIND_LIBRARY(LIBRARY_PATH ...)
> IF(LIBRARY_PATH)
>  blah
> ELSE(LIBRARY_PATH)
>  blah
> ENDIF(LIBRARY_PATH)
>
> That is, the find is performed unconditionally, and the results are 
> used conditionally.  This isn't a bug, it's just a style.  The call is 
> FIND_LIBRARY, not REQUIRE_LIBRARY.  Nothing has been promised about 
> how the results will be used.
>
> There's nothing stopping anyone from writing code like
>
> IF(KDE)
>  FIND_LIBRARY(ASPELL_PATH ...)
>  blah
> ELSE(KDE)
>  blah
> ENDIF(KDE)
>
> but nobody's going to do that without a motive.  It sounds like the 
> real problem here is that conary is improperly designed.
>
it's strange to find something if you are not going to use it
It takes time, resources, but yeah it cheap :)

>>
>> Now about buildrequrements auto-discover.
>> after conary build binary package with configure script it looks in 
>> config.log to discover build requrements of package
>> (ie if configure scripts checks for libaspell.so -> aspell should be 
>> added as build requirements for this package)
>>
>> with cmake based build system i guess CMakeCache.txt is equivalent 
>> for config.log
>> so now conary builds package
>> (ie cmake; make; make install)
>> and then looks in CMakeCache.txt and if it found 
>> "ASPELL_LIBRARIES:FILEPATH=/usr/lib64/libaspell.so"
>> it adds aspell as build requirement for package
>
> Why dos conary assume that a mere path is a build requirement?  That's 
> a bad assumption / a hack.
>
It doesn't assume this. Library dependencies usually descovered from elf 
binaries
(and this is correct way, because if foo uses libbla.so.3.1 it needs 
libbla.so during build)
But also during build often used various binaries (like /usr/bin/zip ) 
and it difficult to discover this
So conary looks on config.log (and in CMakeCache.txt in my tree too) for 
founded paths
then it checks if that path belongs to some installed packages and if 
conary found it,
it tells that this path (package) _probably_ a build requirement. And it 
recipe writer job to check this.
This helps _a_lot_ to get correct build requirements
conary has a tool named rMake to build packages in clean chroot, the 
correct build requirements is really important.
>
>>
>> the problem is that sim-im always tries to find aspell library even 
>> if it will not use it during build
>>
>> so i wonder if there is better way exist to auto-discover real build 
>> requirements of package
>
> That I don't know.  I haven't RTFM on that issue, or needed it for my 
> own work.  I defer to others on this point.  A reliable mechanism 
> would indeed be the basis for a correct conary design.

It's not a bug if conary unconditionally will tell about this build 
requirements, because in real world
this recipie will has:
=========
if not Flags.kde:
   buildRequires.append('aspell:devel')
=========

or something like this. so comment about possibly aspell requirement is 
useful for any case

But i want to make conary as smart as possible :) so if this possible to 
get founded paths,
which is really used during build - i really want to know it :)

-- 
Pavel