incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Karman <pe...@peknet.com>
Subject Re: [lucy-dev] Build from top dir
Date Tue, 07 Dec 2010 03:01:41 GMT
Marvin Humphrey wrote on 12/6/10 6:43 PM:

> 
> However, the PPMC cannot be burdened with QCing and voting on all those
> archives.  There will have to be a single release tarball which is basically a
> snapshot of the repository (probably augmented with some autogenerated files);
> that's what the PPMC, and ultimately the Incubator PMC and the ASF, will
> bless.

I was with you on everything up to this point. Is there some Apache rule that
says that the PPMC cannot be burdened, or that there needs to be a single
release tarball?

Lucy is a complicated project. Are there any other projects at Apache that build
a distinct, stand-alone distribution in multiple target languages? If not, then
I think we're in new territory and we shouldn't try and shoehorn Lucy into any
ill-fitting precedent.

> 
> Some projects at Apache make binary release artifiacts available in addition
> to the source releases.  However, only the source release is official; binary
> releases are considered volunteer efforts.  Dedicated Lucy release archives
> for CPAN, PyPI, etc. would fall under the same classification.

Really? Doesn't a build in perl/ include all the requisite .c/.h files to build
Lucy for Perl? The Perl build isn't a binary release at all; why should it be
classified like an RPM?

I feel like I'm missing something here.

> 
> As an experiment, I've been playing around with moving Build.PL into the top
> level of the Lucy repository.  The rationale is that if we make the Lucy
> repository layout CPAN-compatible, we can reuse the blessed tarball as our
> CPAN tarball as well.  This spares us from having to derive and verify a
> dedicated CPAN distribution tarball, avoiding extra work and lessening the
> opportunity for error.
> 

Why can't we stick with making the perl/-level repository CPAN-compatible, the
ruby/-level repository rubygems-compatible, etc? Each target language should
know how to build itself, in the same idiomatic way that we intend to design
each host language's Lucy implementation.

How about instead a top-level Makefile like this example:

-----------------------------8<------------------
perl-dist: perl/Build.PL
	cd perl && perl Build.PL && ./Build dist

# similar for C-dist, ruby-dist, etc.

# grand dist target
dist: perl-dist C-dist ruby-dist

-----------------------------8<------------------

So to build all target languages, it's a simple:

 % svn up && make dist



-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Mime
View raw message