CPack Packaging for Windows/Mac (and possibly Linux)

[Alexander Neundorf]

On Sunday 24 August 2008, Pau Garcia i Quiles wrote:
> Quoting Sune Vuorela <debian at pusling.com>:
> > On Sunday 24 August 2008 23:25:03 Mike Arthur wrote:
> >> In my experience using CPack however I'm pretty sure we could get the
> >> package generators in such a state that they could be used downstream.
> >
> > My impression (without much look at it) is that the deb support might be
> > producing technically valid debian packages, but not of a quality
> > suitable for debian.
> >
> > .. and some guy within the last months came by debian developer maillist
> > talking about how he implemented the .deb support - and a few mails
> > later he said that he never read the debian packaging policies, but just
> > reverse engineered .deb packages.
> >
> > That has at least convinced me to not spend any further time looking at
> > the .deb support in cmake in the near future.
>
> The main problem I see with .deb packages produced by CPack is they
> are not usable by autobuilders: CPack only produces binary packages,
> not source packages (.orig.tar.gz + .diff.gz + .dsc).

I think the part with the .diff.gz just doesn't match what cpack is supposed 
to do.
There is a project foo (with a cmake buildsystem) developped by Bob. Bob wants 
to create packages for foo. So he adds the cpack logic to his build files.
Now he can create source packages and binary packages (let's start simple 
with .tar.gz).

So the logic for the packaging has been added by the original developer of the 
project. The original developer by definition has no diff against the 
original version, because he creates the original version. 
For the dsc file, it shouldn't be hard to add support for that to cpack.
How should support for a diff.gz look like ?

Alex