Re: Generating debian package using cmake (take 2)
On Mon, Jun 23, 2008 at 9:57 PM, Frank Küster <frank@debian.org> wrote:
> "Mathieu Malaterre" <mathieu.malaterre@gmail.com> wrote:
>
>> 3. I was suggested libopensync for cmake/debian package start.
>> 3.1 where is the internal name 'libopensync1exp3' coming from ? what
>> does the '1exp3' stand for ?
>
> You shouldn't try to invent a new system for building packages if you
> are not familiar enough with Debian Policy to know that yourself.
>
> Sorry, but that's how it is.
Hi Frank,
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.
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.
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 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.
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.
--
Mathieu
Reply to: