--- Paul Eggert <[EMAIL PROTECTED]> ha scritto:
> Claudio Fontana <[EMAIL PROTECTED]> writes:
>
> > There is a missing dependency at least in the
> error
> > module, which should require progname.
>
> No, because some programs define program_name
> without using progname.
> Please see this thr
Claudio Fontana <[EMAIL PROTECTED]> writes:
> There is a missing dependency at least in the error
> module, which should require progname.
No, because some programs define program_name without using progname.
Please see this thread for more discussion:
http://lists.gnu.org/archive/html/bug-gnuli
configure.ac will have to include:
gl_EARLY
gl_INIT
So, no more gl_SOURCE_BASE and gl_SOURCE_BASE in configure.ac?
(They're still in the doc.)
Thanks much for the help.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/m
--- Paul Eggert <[EMAIL PROTECTED]> ha scritto:
> Claudio Fontana <[EMAIL PROTECTED]> writes:
>
> > I'd suggest it is prominently displayed in the
> bug-gnulib manual and
> > error module documentation.
>
> Better yet, there should be some automated way of
> detecting the
> portability problem
Claudio Fontana <[EMAIL PROTECTED]> writes:
> I'd suggest it is prominently displayed in the bug-gnulib manual and
> error module documentation.
Better yet, there should be some automated way of detecting the
portability problem, even when you are testing on a GNU/Linux host
where program_name is
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>>> If I forget to run ./configure ..., I'd rather get a warning
>>> than have GNUmakefile run it for me.
>>>
>>> Providing the rules might be nice, as long as they're hooked to some
>>> nonstandard target.
>
--- Karl Berry <[EMAIL PROTECTED]> ha scritto:
> I would suggest to add this to the GNU coding
> standards:
>
> I'm not sure program_name should be in the coding
> standards. If/since
> gnulib functions require it, then I can see that it
> should be in the
> gnulib doc. But programs t
I would suggest to add this to the GNU coding
standards:
I'm not sure program_name should be in the coding standards. If/since
gnulib functions require it, then I can see that it should be in the
gnulib doc. But programs that don't use gnulib don't necessarily have
to have it. Do they?
Hello,
while using gnulib I stumbled upon a not well
documented 'program_name' symbol requirement.
I would suggest to add this to the GNU coding
standards:
"Each C program should define program_name as a string
of characters (char*), used to store the name of the
program."
I would also suggest
[EMAIL PROTECTED] (Karl Berry) writes:
> First, regarding gnulib-tool --help.
>
> --update isn't mentioned under "Operation modes:", although it is one
> of the usages.
I don't know what --update is supposed to do, so I'll leave it to
others.
> I suggest mentioning that --import can also be used
Simon Josefsson <[EMAIL PROTECTED]> writes:
>> If I forget to run ./configure ..., I'd rather get a warning
>> than have GNUmakefile run it for me.
>>
>> Providing the rules might be nice, as long as they're hooked to some
>> nonstandard target.
>
> Yep, I agree. It should be possible to override
After a brief examination I discovered yet another important bugfix to
argp library undone on the same date (2005-12-12), namely this:
2005-12-10 Sergey Poznyakoff <[EMAIL PROTECTED]>
* argp-fmtstream.c (__argp_fmtstream_update): Fix coredump
I have restored it.
Karl, please do not up
Jim Meyering <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> I'm now using this (with a couple of modifications) in GNU SASL.
>>
>> One thing that struck me as very useful, is the ability to invoke
>> tests without having to autoreconf + configure.
> ...
>
> If I forget
Jim Meyering <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
# Make tar archive easier to reproduce.
export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner
>>>
>>> Those options help minimize unnecessary differences between tar archives.
> ...
>> Still, I think
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Back then, argp-namefrob.h was automatically updated from the latest
> version of the file of the same name in glibc. We no longer do that,
> since the sources have diverged.
It must have been updated by mistake, then.
> Shouldn't the glibc and gnulib so
"Sergey Poznyakoff" <[EMAIL PROTECTED]> writes:
> Somehow the necessary changes to argp-namefrob.h were lost near
> 2005-12-12 (it is marked as 'autoupdate' in the repository, don't
> know what was meant).
Back then, argp-namefrob.h was automatically updated from the latest
version of the file of
16 matches
Mail list logo
