On Sat, Aug 26, 2017 at 10:04:11PM +0200, Mathieu Lirzin wrote: > Gavin Smith <[email protected]> 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.
