Re: Generating debian package using cmake (take 2)
On Mon, Jun 23, 2008 at 11:06 PM, Josselin Mouette <joss@debian.org> wrote:
> 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.
Fine.
>> 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.
Please give such real world examples of failure (if they are
documented anywhere).
>> 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.
I am the maintainer of this particular package. 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).
> And if they all need to go in the same package, you don't need a
> *.install file.
what do you mean all ?
In cmake you simply say:
INSTALL(TARGETS tiffdump libtiff
RUNTIME DESTINATION bin COMPONENT Runtime
LIBRARY DESTINATION lib COMPONENT Runtime
)
INSTALL(FILES tiff.h
DESTINATION include COMPONENT Development
)
Which mean tiffdump and libtiff are part of the 'runtime' package,
while 'tiff.h' is part of the development package.(*)
Thus if you :
cmake -DCOMPONENT=Runtime -P cmake_install.cmake
It will only install the 'Runtime' components.
> Most of the stuff in debian/ is NOT duplicating anything. It is the
> required information to build a package.
That's what I call duplicate information:
http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/gdcmutils.install?view=markup
This file could have been generated from the info contained in the
following cmakelists.txt
http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/Applications/Cxx/CMakeLists.txt?view=markup
while this file:
http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/libgdcm20.install?view=markup
could have been generated from the info contained in the following
files (where * stand for Common, DataDict...):
http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/Source/*/CMakeLists.txt?view=markup
So the question is now: are the files debian/libgdcm20.install &
debian/gdcmutils.install the right way of doing it (I was suggested
the opensync package if that matter). Else how do you automatically
generate them, so that they are always in sink with the dev team ?
>> 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.
I do not understand this either. For instance, my cmakelists.txt
contains this particular line:
FIND_PACKAGE(ZLIB REQUIRED)
I thought I could just add an entry for the Build-Depends teling it
that zlib-dev will be required...
I understand that I may miss some (debhelper for instance), but
technically all dependencies should be listed in the cmake project.
Otherwise it's the developper's fault if they are missing a dep (and
not the packager's fault)
Please details your thought for simple cases.
>> 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.
Very funny.
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 ?
Thanks for your time,
--
Mathieu
Reply to: