Re: Generating debian package using cmake (take 2)
On Tue, 2008-06-24 at 00:20 +0200, Mathieu Malaterre wrote:
> > Stop. Don't even try to go further. This is NOT the right way. Your
> > brand new wheels are going to drive you straight into a wall after way
> > too much effort.
>
> Please give such real world examples of failure (if they are
> documented anywhere).
Cross-purposes.
Mathieu - you're coming from the viewpoint of a single package and
trying to make that apply to all packages that would use cmake.
Josselin is working from the viewpoint of all packages in Debian and
trying to make you see that the *right way* is to modify the existing
build tools to work with cmake.
I regularly have cause to review, modify, patch and mangle every build
system used in Debian (just about) and I have had to build a modified
build system around those systems that is able to support cross-building
via each one. The only way to do this is to supply modifications for
debhelper and CDBS, then make individual changes for individual packages
and get those changes filed as bugs in the BTS.
(Yes, I know many here hate CDBS but I say again, CDBS is the easiest
one for me to handle in such a way.)
Over the years, Emdebian and others have tried many other ways of doing
things, including your (doomed) attempt to scale up from a single
package. The right way is to extend debhelper to explicitly understand
cmake and use existing debhelper routines in a cmake-way.
> I am the maintainer of this particular package.
Then I respectfully submit that this is quite obviously the WRONG
package to select for this purpose.
Forget any specific package - work within debhelper alone and create a
system that works for all cmake projects using debhelper meta-data that
is entirely within the current scope of debhelper itself. By all means
test on a particular package (preferably many packages) but do *NOT*
base the entire thesis on a specific package - that way lies lunacy,
believe me. Been there, done that.
If debhelper understands cmake, CDBS will understand cmake via debhelper
and virtually every other build system in Debian will be able to make
the adjustment.
Do *NOT* stipulate that all cmake projects in Debian are expected to
generate their debian/ files using your scheme - reverse the logic and
make your scheme support all possible permutations of files in debian/
and provide the support required to implement those for cmake.
(If for no other reason than that people like me need to be able to
patch your debian/ files to make the package cross-build and comply with
Emdebian Policy without changes being overwritten by cmake.)
cmake is the object here, not the controller.
debhelper is the controller - cmake is the servant. Help the controller
understand how the servant works and get the servant to do things the
way that the controller stipulates.
> I made sure that
> 'cmake-components' actually match what I call a 'typical' debian
> package: runtime libraries, application and dev package. Typically
> cmake will also split installation into development type installation
> vs runtime installation. So yes, there is a way to specify in cmake
> what executable is part of which components (package in debian
> vocabulary AFAIK).
In which case the chances of the system matching any other package made
by a different upstream team approach zero.
> > There is no metadata store to map a build system's requirements to
> > build-dependencies (unlike those we have for shared libraries). Some of
> > us have thrown some ideas to achieve that with pkg-config, but they
> > would be hacks. Achieving them with packages not using pkg-config (or a
> > similar system) does not even look possible in the current state of
> > affairs.
>
> I do not understand this either. For instance, my cmakelists.txt
> contains this particular line:
>
> FIND_PACKAGE(ZLIB REQUIRED)
Insufficient. configure.ac contains lots of lines for finding libraries
and stuff. These lines are an *AID* to collating Build-Depends but not
the complete solution. A 100% calculated build-depends algorithm has not
yet been found.
> I understand that I may miss some (debhelper for instance), but
> technically all dependencies should be listed in the cmake project.
Wrong. You would also need to map Debian package names against upstream
names - many do differ. Other problems lie ahead - honest, this path is
doomed.
> Otherwise it's the developper's fault if they are missing a dep (and
> not the packager's fault)
Tosh.
> Anyway, I have a working cmake-skeleton at least to automatically
> generate the files in gdcm/debian/*, see:
>
> http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/
>
> So I'll rephrase all my previous questions, into this single one: are
> those files the right way of doing a debian package ?
A single package, maybe but it is still the wrong approach.
Get debhelper to work with cmake by making an interface between cmake
meta-data and debhelper meta-data. That is the mapping you need.
Give up generating the debhelper meta-data directly and just get
debhelper to understand how cmake expresses the meta-data and help
debhelper process the cmake data accordingly.
Automated package generation is a mugs game. Packaging for Debian is a
manual task.
--
Neil Williams <codehelp@debian.org>
Reply to: