bug-gnulib
[Top][All Lists]
Advanced

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

Re: dependency creep


From: Sam Steingold
Subject: Re: dependency creep
Date: Sun, 26 Oct 2008 09:43:50 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Hi Bruno,

> * Bruno Haible <address@hidden> [2008-10-26 14:36:46 +0200]:
>
>> I updated gnulib files in clisp and threadlib.m4 was pulled in by
>> gettext 0.17.
>> Are you sure this is really truly necessary?
>
> It is necessary for packages that use
>   AM_GNU_GETTEXT
> but it is not necessary for packages that use
>   AM_GNU_GETTEXT([external])
>
> In the latter case, I thought that 'aclocal' will determine that the file
> threadlib.m4 is not needed, not include it from aclocal.m4, and thus
> "make dist" will create a tarball without this file. No?

we have
AM_GNU_GETTEXT([external], [need-ngettext])
whatever that means.
threadlib was pulled in.
I am sure you have the clisp cvs tree somewhere - do "cvs up".
You can see that I use aclocal 1.10 and autoconf 2.62.

>> I thought of replacing clisp/src/execname.c (158 lines which determine
>> the truename of the current executable) and discovered that to do that I,
>> apparently, need the relocatable-prog-wrapper module (17 C and H files!
>
> Determining the truename of the current executable is not yet a supported
> functionality of its own. You found some uses of this functionality in the
> relocatable-prog-wrapper module, which does many more things.
>
> So, would you like to propose a module that determines the truename of the
> current executable? This would be a new API, because neither POSIX nor
> glibc have this API.

yes. I think the API currently used by clisp (clisp/src/execname.c) is
good enough:

/* find and save the executable name from argv[0] */
int find_executable (const char * program_name);
/* access the stored executable name */
char *get_executable_name (void);

>> So, what is the point of gnulib again?
>
> The point of gnulib is to allow you to program with reference to POSIX
> or the glibc documentation, using the same includes that work on glibc
> platforms, and then fix a maximum of portability programs by telling
> gnulib-tool to import the relevant cross-platform support.
> Additionally, it provides generally useful utility functions.

good - so I thought.

>> Why not just distribute gnu libc with every application?
>
> 1) Because glibc is not ported to OSes from AIX to Windows. There was once a
>    port of glibc to AIX, but it became quickly unmaintained (after IBM stopped
>    paying for it).
> 2) Because gnulib does more than glibc: It does not override the functionality
>    of the system that is present and works. Like two gear wheels fit together,
>    gnulib adapts to the shape of the system's gear wheel.

the sad part is that you apparently did not notice my sarcasm.
what if I said
>> Why not just distribute the whole gnulib with every application?


at any rate, as a gnulib user, I would like to humbly request that you
pay more attention to minimization of the amount of the overridden
functionality.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 8.04 (hardy)
http://israelunderattack.slide.com http://pmw.org.il
http://mideasttruth.com http://thereligionofpeace.com http://ffii.org
Linux - find out what you've been missing while you've been rebooting Windows.




reply via email to

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