Re: Bug#949789: Please provide a makefile snippet with common variables used during building perl modules

[Dominic Hargreaves <dom@earth.li>]

On Tue, Feb 04, 2020 at 07:36:34PM +0100, gregor herrmann wrote:
> > The specific usage in
> > libcdb-file-perl (removing a file installed to vendorarch after the
> > build) could be circumvented with a wildcard afaics, but I don't think
> > that works for the general case.
> 
> Ack.
>  
> > I guess this can't be provided by debhelper perl_* build systems because
> > the vendorarch path needs to be available to the top level make and the dh
> > subprocesses can't affect that.
> 
> Makes sense.
>  
> > So I'm OK with centralizing this somehow in perl-xs-dev (aka. libperl-dev).
> 
> Hm, perl-xs-dev is only needed for arch:any packages but we might
> want to add other variables which are (also) used in arch:all
> packages as well.

I don't think it hurts to ask packages needing this to build-dep on
libperl-dev if they need access to this variable. I don't think we should
ship such a file in a non-dev package, unless we have a clear and
reasonable runtime use for it (my worry is that people will start
using it for the wrong thing otherwise, which will make it harder to
change later).

On Fri, Feb 21, 2020 at 12:06:06PM +0100, gregor herrmann wrote:
> PERL_CURRENT := $(shell perl -MConfig -e 'print "$$Config{revision}.$$Config{patchlevel}.$$Config{subversion}"')
> PERL_NEXT    := $(shell perl -MConfig -e 'print "$$Config{revision}.$$Config{patchlevel}." . ($$Config{subversion} + 1)')
> 
> That might be a good candidate (maybe as PERL_VERSION-*).
> 
> Similar:
> PERLVER := $(shell perl -MConfig -e 'print $$Config{version}')
> 
> 
> ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
> INDEPLIB := $(shell perl -MConfig -e 'print $$Config{vendorlib}')
> 
> That's what started the discussion; I guess we might just use the
> "real" names, so maybe PERL_CONFIG_VENDORARCH etc.
> Maybe it would make sense to just expose all %Config keys?

My concern about doing that is that (similar to my point above) it
exposes a much wider interface, that we might not want to maintain.
I'd rather expose a small number of known requirements (in a
predictable namespace like you suggest); we can easily add more later.

We should mention in the documentation that users should file a bug
against perl if they think that more variables should be added.

Cheers
Dominic