[vsipl++] [patch] Source configuration for package.py

[Mark Mitchell]

Sorry for the brief reply -- Treo typing...

1.  It might be a good idea to look at the SG++ release configs.  We would handle this situation by having a different SVN URI in the two configs.

2.  For good or ill, we  never use patches on SG++.  For the font size issue, we would just make a branch.  Branches are cheap. :-)

FWIW,

--
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-6685 x713
-----Original Message-----
From: Stefan Seefeld <stefan at codesourcery.com>
Date: Thursday, Apr 19, 2007 2:42 pm
Subject: Re: [vsipl++] [patch] Source configuration for package.py

Jules Bergmann wrote:
 
> Jules,
>
> I have a couple of high-level questions:
>
> 1) Why do you keep the source configuration in a new file, instead of
>    integrating it into the existing 'config' machinery ?
 
 I think merging the two would be a good idea, however because of
 orthogonality (the choice of source modules is mostly independent of how
 the binary packages are built) and ignorance of python, I have them
 separated right now.
 
 Is there (and there must be, it is python!) a good way to include one
 configure file from another?

from other_config import *

? :-)

I'm not sure I understand the orthogonality argument. The config file contains everything that needs to be known to build packages. And that includes compilation flags, and may well include information about
where to obtain the sources from.

You are right, though, that we may set up two such config instances, and multiply them with the existing package instances to get a commercial as well as a gpl version for each package.
In that respect it's just another (new) parameter to the packaging harness.

> That would allow the 1.3.1 commercial config to be:
 
     cfg.svpp_dir='csl/vpp/branches/1.3'
     cfg.fftw_dir='csl/fftw-commercial/trunk'
     cfg.patches=['docbook.diff']
     include standard_config
 
 and the GPL config to be
 
     cfg.svpp_dir='csl/vpp/branches/1.3'
     cfg.fftw_dir='csl/fftw/trunk'
     cfg.patches=['docbook.diff']
     include standard_config
 
 Where 'standard_config' is the current 'config' file.

Yep.

>> 2) Why do we apply patches to a fftw working copy, as opposed to keeping
>    them merged in the repository ? (why don't we use a branch for that ?)
 
 Are you asking about the 'cfg.patches'?

Yes.

> That isn't necessarily for FFTW.  In putting out the past releases, I've
 found that prior to getting everything just right, there are usually a
 small number of changes necessary.  Rather than checking in each change
 individually and starting a new build, I collect them up in a patch that
 is applied to the checkout.  Once everything is in order, that patch
 gets checked in so the final build is from a clean checkout.
 
 So ideally for the final package, the patches list would be empty.

Hmm.

> However ... the patch mechanism also lets us work around things like the
 font size issue in docbook.  That is how it is being used above.

Are you saying