Re: [PATCH] Add 'pre-inst-env' wrapper script

[Gavin Smith]

On Sat, Aug 26, 2017 at 10:04:11PM +0200, Mathieu Lirzin wrote:
> Gavin Smith <address@hidden> writes:
> 
> > On Sat, Aug 26, 2017 at 06:41:47PM +0200, Mathieu Lirzin wrote:
> >> Hello,
> >> 
> >> While hacking on 'texi2any' and testing my changes with manuals located
> >> in various places in the filesystem, I found it cumbersome to launch the
> >> non installed 'makeinfo' like this:
> >> 
> >>   TEXINFO_DEV_SOURCE=1 top_srcdir=~/src/texinfo/trunk \
> >>     ~/src/texinfo/trunk/build/tp/makeinfo --html hello.texi
> >> 
> >
> > You can do
> >
> > ~/src/texinfo/trunk/build/tp/texi2any.pl --html hello.texi
> >
> > instead. This is hinted at in the README-hacking file, but maybe it 
> > isn't as clear as it could be.
> >
> > (The paths to the installed locations are inserted into texi2any.pl to 
> > create texi2any, to which makeinfo is a link.)
> >
> > So I don't think that a wrapper script is necessary here.
> 
> I have read this, however this doesn't work when using an out of tree
> build.

I think I understand; there are files in the build area that texi2any 
needs to use, most notably Texinfo/ModulePath.pm but also the XS 
modules.  If texi2any.pl is run with no environment variables set,
it doesn't know where the build dir is, only the source dir (from the 
location of texi2any.pl itself).

If I understand your proposal correctly, it is a script that sets 
environment variables so that programs can find both the srcdir and 
builddir and tells them to use files in those directories, not in any 
installed locations. That seems like a good idea, then.

> It is possible to not use a wrapper script and support out of tree
> builds, by substituting the location of the local modules in 'texi2any'
> at configure/make time and then replace those at install time with the
> location of the installed modules.  However the down side of this
> approach is that it requires to handle how perl tests find their modules
> separately.

I don't know what the implications are for the tests, but if it can 
make the code base simpler or reduce the number of locations in the code 
base that have to be updated together, then that would be a good thing. 
The Texinfo::ModulePath module was for this purpose, if I remember 
correctly, where previously the same list of @INC directories was given 
in several places.