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