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

[Stefan Seefeld]

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 that such small a patch isn't worth a branch ?

>> 3) How is the fftw working copy combined with the vpp working copy after
>>    the checkout ? (sorry if that is obvious from the code, I couldn't
>> find
>>    the related code)
> 
> Good question.  We've designed our build system to pretty much use a
> stock FFTW source package without modification.  The FFTW working copy
> is placed in the VSIPL++ working copy's vendor/fftw directory.  That's
> it!  Sort of a manual external.

OK, that's what I suspected. Thanks for confirming it ! :-)


Thanks,
		Stefan

-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718