Re: Generating debian package using cmake (take 2)
On Tue, Jun 24, 2008 at 12:54 AM, Neil Williams <codehelp@debian.org> wrote:
> 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.
I do not believe I said cmake would take over the whole debian package
system tomorrow, but I see your point. Indeed, I am only focusing in
getting (in too little time) debian package for a particular set of
limited package.
> 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.)
I had to work the other way around. Install cmake-based project via
official debian package, only to realize installation was broken.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486794
That's were I started to think of a better collaboration in between
debian package system and cmake...
> 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.
THANK YOU !
So far I only had FUDs about: 'no this is impossible, 'this is not the
right way'. Thanks for taking the time to answer in detail, this much
more supportive. I finally understood the previous aggressive answers,
I was simply looking at the problem from opposite direction.
So the next question is: where do I get started :)
>> 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.
Yeah well, say that to upper management :)
Sorry been under too much pressure, I'll give up on my half born
project cmake-driven debian package generation and start looking into
integrating cmake into debhelper.
> 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.
ok.
> 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.
Ok. I'll need to learn debhelper terminology.
> (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.
ok.
>> 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 still do not understand this one. cmake is able to say I need
'zlib.h' and 'z.so', so I do not see why this is so hard to find out
that zlib-dev is required (dpkg -S, or equivalent call), right ?
>> 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.
ok.
>> 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.
I was only targeting at getting part of the work done. Anyway I'll
start looking into debhelper ASAP.
Anyway, that was very instructive, thanks for your time.
--
Mathieu
Reply to: