lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] Build from top dir
Date Fri, 10 Dec 2010 02:59:10 GMT
On Wed, Dec 08, 2010 at 08:23:18PM -0600, Peter Karman wrote:
> > 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.
> -1 to esoteric.
> how about "sample_docs" ?

That'll work!

> fwiw, I also tire of perl MANIFEST upkeep. I now do this:
>  % make manifest && make dist

The 'dist' build target from Lucy::Build does the same thing.  We *have* to
build MANIFEST on the fly at dist time because up until that point, the
core/, charmonizer/, clownfish/ and devel/ directories all live one level up.

So, even if we maintain a trunk/perl/MANIFEST file, it will get overwritten
with a new one when we build the CPAN tarball.  The sole reason to keep
trunk/perl/MANIFEST around is to avoid warnings from Module::Build when
running Build.PL from either an svn checkout or the official ASF release of

FWIW, I snooped the code in Module::Build and there's no practical way to get
rid of those warnings short of providing a MANIFEST.  I even considered having
Build.PL generate a faked up MANIFEST on the fly whenever it gets run, but
decided that was too nasty a hack.

> and I have a MANIFEST.SKIP file, e.g.:
> since I find it easier to blacklist files I do *not* want rather than keep up
> with files I *do* want.

If we aggressively maintain MANIFEST.SKIP, that makes things a little easier,
but in my experience building MANIFEST in a dirty directory tends to scoop up
things like little test scripts I hacked up.

Maybe we can create a fake_manifest build target that adds everything under
trunk/perl/ which is in svn?  I.e. we accept that we have to maintain the
stupid MANIFEST, but at least we make the maintenance less labor-intensive?

Marvin Humphrey

View raw message