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
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
