Le lundi 23 juin 2008 à 22:11 +0200, Mathieu Malaterre a écrit : > That's just rude. Even if you are a super star in the debian-world > and a fantastic hacker, your comment can not possibly be coming from a > grown up adult. Rude? Come on. You are trying to reinvent the wheel in the worst possible way, without understanding what a wheel is for and without obviously reading the documents that explain what are wheels and how to make them (Debian Policy and New Maintainer’s guide). Starting from that, Frank could have been much more rude. > You did NOT even try to make a tiniest effort to understand what I > am doing here. I am NOT reinventing the wheel here. As I said in the > very first line of my email, I understood my previous mistake in the > early implementation of debian package. That's why I am doing it the > 'right' way (as I have been suggested in the previous thread in this > very same mailing list). > The output of cmake will be a bunch of files: control, > libfoo.install, so that you can run dpkg-buildpackage as any other > debian package. 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. > Why am I doing that ? Because *this is reinventing the wheel* when > you use cmake and duplicate code in *.install file instead of simply > asking cmake to generate those file for you. If you had read the wiki > page I send, all the information is in the cmakelists, just not > available as regular debian package files. The cmakelists will not tell you in which package the files have to go. And if they all need to go in the same package, you don’t need a *.install file. Most of the stuff in debian/ is NOT duplicating anything. It is the required information to build a package. > The other goal is to also export cmake dependencies (cmake is doing > system inspection), so that one should not have to write the > 'Build-Depends' line. cmake knows what is needs to compile, so indeed > this line is purely machine generated. 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. > As I said, I understand that some info (Conflicts typically) will be > human generated, but I am sure that 95% of writing control/*.install > file can be automatically generated by the build system: cmake in my > case. As far as I understand generating those debian files can be > tedious and error prone, plus it duplicate the logic in cmake anyway. > This should remove most of the boiler plate code, when a project is > using cmake. Instead of trying to make funny and stupid things that will entertain us for months, looking at you drowning in your brain-dead system, you should try to write patches to make cdbs and/or debhelper 7 work transparently with cmake. This is the right way, and it requires much less effort than building a car with square wheels. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=