[Top][All Lists]
[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.