incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] Build from top dir
Date Wed, 08 Dec 2010 18:38:26 GMT
On Tue, Dec 07, 2010 at 08:41:10PM -0600, Peter Karman wrote:
> Chris Hostetter wrote on 12/7/10 8:29 PM:
> 
> > 1) Although the lucene release haven't really set a good example of this, 
> > the mantra Juka has always evangalized that i've come to appreciate is 
> > that the "source" release should essentially be "svn export | tar | gzip"
> > 
> 
> +1

OK, great!  The path forward starts to look clear.

First, I'll close <https://issues.apache.org/jira/browse/LUCY-130> as a
wontfix.  We'll keep the basic layout we have now, and you'll still need to cd
into a host language dir to build for a given target.

Next, we have to rearrange the sources a bit.  Changes and README should move
up one level, out of trunk/perl/ into trunk/, where they will become shared.
README's content will have to be generalized.

We probably want to move the sample US Constitution corpus, too, up out of
trunk/perl/sample/us_constitution/ -- but that's a little tricky, because
trunk/perl/sample/ also contains a bunch of Perl apps.

My first take is that each host language subdirectory should have its own
sample directory, i.e. this...

    trunk/corpora/us_constitution/
    trunk/perl/sample/
    trunk/python/sample/
    trunk/ruby/sample/

... and not this:

    trunk/sample/us_constitution/
    trunk/sample/perl/
    trunk/sample/python/
    trunk/sample/ruby/

Since IMO it would be confusing to have "sample" directories both at the top
level and within host language dirs, I think the new destination for the
corpus should be $dist_root/corpora/us_constitution/ -- which would be found
at the top level of both the ASF release and the downstream packages.  The
word "corpora" is kind of esoteric, but oh well.

MANIFEST is a little more annoying.  I got tired of forgetting to update
MANIFEST and started autogenerating it at dist build time, living with
warnings when building from SVN checkout.  However, if the ASF release is just
a snapshot of the repository, we'd also get those warnings when building from
the official tarball, which is less cool.  And Build.PL needs MANIFEST
immediately nearby -- i.e. at trunk/perl/MANIFEST, so trunk/MANIFEST won't do.
Do we really have to start maintaining trunk/perl/MANIFEST, and do we need
another one at the top level?  Maybe we need a "prepare_commit" build target
which verifies that various MANIFEST files are up-to-date, or something.  I
guess until there's a plan, I'll put this one off...

After that, we have to fix the Perl "dist" build target.  Right now it will
snag the core/, charmonizer/, clownfish/ and devel/ directories, but it also
needs to grab all the stuff that has moved around.

The names for the downstream builds will all be customized according to what's
best for the dist channel, and won't follow the conventions of either the
Incubator or the Qpid example...

    ASF release:  lucy-0.1.0-incubating.tar.gz
    CPAN release: Lucy-0.1.0.tar.gz

... but we'll have to add a note somewhere to indicate that the CPAN release
is not an official ASF package:

    http://incubator.apache.org/guides/releasemanagement.html#best-practice-downstream

    Need to add notes that these are not official releases.

Lastly, thinking about non-Perl downstream distros like PyPI, PEAR, etc...
we'll autogenerate all files which depend on Clownfish (and therefore Perl) at
*dist* build time.  Thus, you'll still need Perl to build Lucy from the
official Apache source release, but if you obtain Lucy from a dist channel
like PyPI, you won't.

Marvin Humphrey


Mime
View raw message