[CMake] cmake integration

[Eric Noulard]

2007/2/9, Pavel Volkovitskiy <int at mtx.ru>:
> >
> > 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 :)

I think that finding something you may not use
is possible with autotools (AC_CHECK_xxxx) as well as wtih CMake.

CMake has the notion of OPTION which is a kind of
autotools --enable/disable --with[out]  feature.

The fact that some CMake (resp. autotools) user may
FIND_PACKAGE (resp. AC_CHECK_xxx) something but
--disable the feature that effectively use it the responsibility
of the CMakeLists.txt (resp.  configure.ac) writer.

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

You may try to discover requirement but from my point of view
you try to re-discover what the CMakeLists.txt writer has done
when putting it's FIND_PACKAGE directive, I would rather go
for directly parsing CMakeLists.txt files for FIND_xxx directives
(your may get a list from cmake --help-command-list | grep FIND)

It will brought you search PACKAGE/PATH/PROGRAM/LIBRARY.

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

I think you'll have to assumer that if someone is looking for a package
it MAY be required for the build.
The fact that you do not find the search package or LIBRARY may
well modify what you MAY build or not.
>From my point of view this is precisely the aim of CMake/Autotools.

Finding the MANDATORY requirement for build is though difficult.
I build a sofwtare package which depending on what is found
on the build host build between 4 and 15 executables.
The more you have the more you get, but if you only NEED the first
4 others are NOT MANDATORY.


You are right the MANDATORY dependency for BINARY installation
is more clear: get the list of (dynamic) libraries you depends on.
For this analysis a "ldd" on each produced executable/lib will do
the jobs.

When you found the library you depend on
ask the "package installation system"
(rpm, dpkg, emerge, ...) whose package OWNS this lib
and you get the BINARY INSTALLATION dependencies.


> >> the problem is that sim-im always tries to find aspell library even
> >> if it will not use it during build

Then sim-im should get ASPELL dependency, the developper made
this "choice" of over-dependency.

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

I think you mix-up binary install dependency/requirement
with build dependency.
As I said ealier if you don't have an apparently "required" package
the build resulting from CMake configuration may well succeed
with a somehow "smaller" set of executable/library.


> But i want to make conary as smart as possible :) so if this possible to
> get founded paths,

You get:

 - searched path with searchinf for FIND_PATH in CMakeLists.txt
 - found path in CMakeCache.txt

> which is really used during build - i really want to know it :)

 - really tough, I think you should not try to be smarter
    than the developpers of the package you are building.

Now the discussion may go on the definition of the objectives
of conary, but I don't know if CMake ML is where it should be discussed.

Cheers,
-- 
Erk