Mailing-List: contact lucy-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Mon, 27 Feb 2012 18:29:41 -0800
From: Marvin Humphrey <marvin@rectangular.com>
To: lucy-dev@incubator.apache.org
Message-ID: <20120228022941.GA3166@rectangular.com>
References: <20120224205425.GA16270@rectangular.com>
 <4F48B81B.8030705@aevum.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F48B81B.8030705@aevum.de>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [lucy-dev] Header file installation

On Sat, Feb 25, 2012 at 11:29:47AM +0100, Nick Wellnhofer wrote:
> On 24/02/2012 21:54, Marvin Humphrey wrote:
>> We can provide similar functionality from Lucy.pm.  Here's how a build script
>> for a distro which extends Lucy might use it:
>>
>>    eval "use Lucy;";
>>    if ($@) {
>>      warn "Can't load Lucy;
>>      exit(0);
>>    }
>>    my $include_dirs = Lucy->include_dirs;
>>    my $inc = "";
>>    $inc .= "-I$_ " for @$include_dirs;
>>
>> At first, I imagine include_dirs() returning only a single directory.
>> However, in the future we may break out Clownfish, and perhaps include_dirs()
>> should return the include paths for recursive dependencies:
>>
>>    package Lucy;
>>    use Clownfish;
>>
>>    sub include_dirs {
>>      my $dirs = Clownfish->include_dirs;
>>      push @$dirs, _lucy_include_dir();
>>      return $dirs;
>>    }
>
> +1

I thought of a refinement we might consider.

It seems to me that having one include dir per distro is asking for trouble.
What happens when LucyX packages extend each other?  At best, we will start to
see very long compilation commands because of all the -I directives; at worst
we will lose track of an include dir and be in for some annoying debugging.

Better would be one dedicated include dir per *host language* which will house
headers for all Clownfish-related distros -- something analogous to
/usr/local/include, but one for /usr/local/bin/perl, one for /opt/myruby/,
etc.  So long as each header file must be named after a class it contains, we
shouldn't see distros clobbering each others' files.

>> For the actual header tree, how about a dedicated directory at the following
>> location?
>>
>>      catdir( $ARCH_DIR, 'auto', 'Lucy', '_include' );
>
> Here are some other modules that I found that install header files:
>
> http://packages.debian.org/sid/amd64/pdl/filelist
> http://packages.debian.org/sid/amd64/libglib-perl/filelist
> http://packages.debian.org/sid/amd64/perl-tk/filelist
>
> They don't put the .h files below 'auto' which makes sense, because  
> afaics 'auto' should only contain files used by AutoLoader.

Interesting.  After reviewing the Perl module load path mechanism, I concur --
we should follow your suggestion and not DBI's example.

> I like the idea of an '_include' directory, so I would propose:
>
> 	catdir( $ARCH_DIR, 'Lucy', '_include' );

+1 for dropping 'auto'.  Here's what I'd now suggest:

 catdir( $ARCH_DIR, 'Clownfish', '_include' )

Let's also consider what we mean by $ARCH_DIR.  Ordinarily it will be this:

  $ perl -V:installsitearch

The theoretical possibility exists that in the future it might be this:

  $ perl -V:installvendorarch

For more information, see the following:

  http://perldoc.perl.org/Module/Build.html#INSTALL-PATHS
  http://search.cpan.org/~leont/Module-Build-0.40/lib/Module/Build/API.pod#install_destination
  http://perl5.git.perl.org/perl.git/blob/cc92ef02098c000d945bcf93c92bdb2a0a05fa97:/INSTALL#l508

The dir would actually be derived within Lucy::Build like so (note: $self is a
Lucy::Build object):

    my $arch_dir = $self->install_destination('arch');
    my $include_dir = catdir( $arch_dir, 'Clownfish', '_include' );

Marvin Humphrey