-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Alfred M. Szmidt on 7/21/2008 9:30 PM:
| Why can not just a simple _warning_ message be displayed at the end of
| the run instead? That does not punish anyone, and users are informed
| that they installed something that has stale cruft i
Why can not just a simple _warning_ message be displayed at the end of
the run instead? That does not punish anyone, and users are informed
that they installed something that has stale cruft in it, and they can
easilly do `make uninstall', `make all' or whatever to fix it; or
simply ignore it.
T
Hi Yoann,
Yoann Vandoorselaere wrote:
> > I think you can effectively already do it. Like this:
> >
> > gl_LOCK
> > if test $gl_threads_api = pth; then
> > AC_FATAL([The pth threads implementation is not supported by this
> > package.])
> > fi
>
> Thanks! Wouldn't it be better to dire
Bruno Haible clisp.org> writes:
>
> Eric Blake wrote:
> > I still stand by the claim that making 'make install' error out on
> > version mismatch will only affect people trying to install an unreleased
> > development snapshot who have changed the VCS tree since the last time they
ran
> > a
Eric Blake wrote on Friday:
> In the developer's sandbox, you should not care what the version is,
> therefore,
> development and incremental compiles should NOT be penalized by always
> keeping
> the version string up-to-date. But once you type 'make install'
> without .tarball-version, you
Eric Blake wrote:
> I still stand by the claim that making 'make install' error out on
> version mismatch will only affect people trying to install an unreleased
> development snapshot who have changed the VCS tree since the last time they
> ran
> a full autoreconf.
It just feels wrong to me.
On Sun, 2008-07-20 at 13:45 +0200, Bruno Haible wrote:
> Hi Jim,
>
> > What do you think about relicensing canonicalize-lgpl to lgplv2+?
> > Among its dependents, a quick glance suggests only readlink would
> > need the same adjustment.
>
> No problem with doing that. We promised this to everyone
Eric Blake <[EMAIL PROTECTED]> wrote:
...
> How about this patch?
...
> Subject: [PATCH] Don't allow installation with stale devel version number.
...
> +# must run 'autoreconf' (or something like 'make distcheck') to
> +# fix the version, 'make all' to propogate it, then 'make inst
Ondřej Vašík <[EMAIL PROTECTED]> wrote:
...
> Where should I document current the changes? In gnulib getdate.texi
> only? Or in both gnulib and coreutils documentation?
Hi Ondřej,
Documenting in getdate.texi will be enough, because that file is
included by coreutils.texi. Thanks!
Paul Eggert CS.UCLA.EDU> writes:
> > One other possibility I've thought about. We could have 'make install'
check
> > git-version-gen, and abort rather than install if it is out-of-date with
> > reality (of course, if .tarball-version exists, it will never be out-of-
date).
Actually, in test
Sam Steingold wrote:
Bruno Haible wrote:
Sam Steingold wrote:
OK - I am both proposing a patch AND asking a particular person
(Bruno Haible).
OK, but please keep bug-gnulib in CC.
OK. looks like Ben's advice worked wonders, so I will try that again:
I am both proposing a patch AND asking a p
Hello,
Jim Meyering wrote:
> I'm a little leery of this patch, because it makes interpretation
> of UTC+dd and UTC-dd dependent on the value of dd. For dd <= 14, dd
> represents hours. Otherwise, it represents minutes. That would have
> to be documented, but seems odd enough that my reflex is to
Hi Bruno,
Le lundi 21 juillet 2008 à 12:24 +0200, Bruno Haible a écrit :
> > - Ability to disable specific backend on demand: some implementation use
> > certain functionality that are incompatible with libpth, or depend on
> > library that provide pthread support but no libpth support. As a resul
Hi Yoann,
> - Ability to disable specific backend on demand: some implementation use
> certain functionality that are incompatible with libpth, or depend on
> library that provide pthread support but no libpth support. As a result,
> it would be great if it was possible to explicitly disable a giv
Hi,
I would be interested in performing the following lock module
modification:
- Ability to disable specific backend on demand: some implementation use
certain functionality that are incompatible with libpth, or depend on
library that provide pthread support but no libpth support. As a result,
i
15 matches
Mail list logo
