On Tue, Jun 24, 2008 at 12:54 AM, Neil Williams <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
