texinfo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: texi-elements-by-size as example


From: Patrice Dumas
Subject: Re: texi-elements-by-size as example
Date: Mon, 16 Apr 2012 20:29:37 +0200
User-agent: Mutt/1.5.20 (2009-12-10)

On Mon, Apr 16, 2012 at 08:59:33AM -0700, Karl Berry wrote:
> Hi Patrice,
> 
>     Date: Fri, 17 Feb 2012 19:12:51 +0100
>     To: address@hidden
> 
>     [...]
>     That was not really my point, my point is that the 
>       texi_sort_elements_count.pl
>     script could be used as a starting point for any command line program
>     written in perl that interfaces with the parser, 
> 
> Ok, that sounds good.  In that case, I think a bit more work is needed
> to make it serve the purpose.  As an example program, it shouldn't
> require the configure from texinfo (as in the @datadir@/@PACKAGE@
> stuff).

Agreed.

>  And in general, it requires that Texinfo/Parser.pm and the
> dependent libraries like Unidecode.pm be in an installed Texinfo tree,
> which seems unnecessarily restrictive to me.  For example, I cannot run
> it myself. :)

Not necessarily.  It can also be simply installed like every perl modules
are.

> The directory containing Texinfo/Parser.pm is simple to include in @INC,
> whether computed inside the program or by perl -I or whatever.  The main
> problem is finding the non-Texinfo libraries which the Parser wants to
> read: currently Locale::Messages, Unicode::EastAsianWidth, and
> Text::Unidecode.

My proposal would simply be to document that those packages are needed,
give their name for Fedora and debian based distros, and any other
distro we have information on, and let the user install them himself.
As most of the distros have a no bundled libraries policy, the packages
should exist anyway, as soon as texinfo is packaged in major distros.

> That list may change.  Besides that, we surely don't want to duplicate
> the complex logic from texi2any.pl for finding them in any program that
> wants to use TP.  I'm not sure if it will work, and maybe you will have
> a better idea, but here's my initial thought -- what if we provide an
> interface that would be used from BEGIN, something like this:
> 
> BEGIN {
>   my $texinfolibdir = "../tp"; # just for testing, obviously needs 
> generalizing
>   unshift @INC, ($texinfolibdir);
>   #
>   require Texinfo::Init;
>   Texinfo::Init::init();  # load the needed libraries
> }

I don't think we want to duplicate the perl use mechanism in general.
In texi2any it is fine, because we want to be as self contained as
possible, but in general, I think that we should not try to isolate from
perl mechanisms.  So my proposal would be not to try to do anything
smart but instead document what are the needed perl modules.

> Ideally texi2any.pl could use the same code, to avoid duplication, but
> I'm not sure if that would be possible.

I don't know, but I'd prefer not to go there...

Remembering my days as a Fedora packager, if I were to package the new
texinfo in Fedora, I would first do 

  rm -rf tp/maintain/lib

having patched out install-data-local from Makefiles, and then I would
thrive to install all the modules in standard perl locations, if
possible using standard perl installs.

-- 
Pat



reply via email to

[Prev in Thread] Current Thread [Next in Thread]