cctbx and pkgconfig

[Picca Frédéric-Emmanuel]

On Tue, 7 Aug 2012 08:48:27 +0200
Radostan Riedel <raybuntu at googlemail.com> wrote:

> OK, I just put in each line to be sure the build system is creating every pc
> file and I'd get an error in gbp.

yes indeed.

> > Usually the pc files are generated from a .pc.in file. [1] or even better [2].
> > maybe providing this kind of xxx.in -> xxx file generator would be valuable for their build tool and then easier to
> > sell ;)
> I saw that builder too. I wanted to restructure that patch to run that function
> as a postaction in the sharelibrary builder. But this can also work with that
> pc.in file. I'm just not sure about the copyright of [1] and [2] and I know I'd
> have to document this.

Yes your are right, the license of the code should be clearer on the
scons site. A few Builder have a proper license header but not [1] and
[2], it is a shame. Nevertheless we should ask for the license on the
scons wiki. maybe there is a default one.

> About talking with the upstream. I want to provide a patch that will work right
> away. I tried git-import-orig to import the new dfsg upstream tarball. Problem
> is that the patches do not apply anymore when I do a "gbp-pq import".
> It's not really verbose why it didn't work. Is there something I'm missing or do
> I have to patch everything again "manually"?

Yes this is the problem with too many patch not integrated upstream. I
had this problem with other project and I spend a lot's of time working
with the upstream for the patch integration. At the end it is very
fruitfull but hey it is a lot's of work.
Normally the things to do with gbp-pq is to use the rebase command
instead of import.

This way you are doing a standard git rebase things on top of a new master branch.
If you just do and import it is more painfull.

You will see which part of your patches are problematic and which one are not.
It would be nice to integrate into the upstream svn first the
problematic one to avoid this recurent rebase issue.

Maintaining a software with such a specific build-system is very
painfull if you do not do it with the upstream.
repeat after me the mantra : "I will push my patch to the upstream" :))

maybe you should discuss about your patch series ideas with the
upstream and when you agreed on one of thoses patches, you can work
directly from their svn. Then you should become a normal contributor to
the cctbx project.

using the stable release as a starting point for the patch is not a
good solution from the upstream point of view.
They should prefer a patch on top of their svn trunk...

Then you should simplify the patch series step by step with the next
upstream upload.

So before importing the new upstream you do a:
1) gbp-pq import
2) switch to the master branch
3) gbp-import-orig
4) gbp-pq rebase

if I am correct.

Cheers

Frederic

-- 
GPG public key 4096R/4696E015 2011-02-14
    fingerprint = E92E 7E6E 9E9D A6B1 AA31  39DC 5632 906F 4696 E015
uid  Picca Frédéric-Emmanuel <picca at synchrotron-soleil.fr>

GPG public key 1024D/A59B1171 2009-08-11
    fingerprint = 1688 A3D6 F0BD E4DF 2E6B  06AA B6A9 BA6A A59B 1171
uid  Picca Frédéric-Emmanuel <picca at debian.org>