Hello.
Alexandre Duret-Lutz wrote:
[snip]
A suggestion was to always use `SHELL = /bin/sh' in Makefiles.
I simply don't know how correct this is, because that's how it
was in the past before Chris Provenzano changed it to what it is
now. The reason for that change seems to have been lost.
Because
Here is the patch I'm installing. Besides the doc update, and
the cpio -H $1 -i thing, I also changed the name of the cache
variable to include the _AM_PROG_TAR argument (so that
subpackages with different tar-xxx option do not share the same
cache variable).
As I've said, I'm also deliberately t
>>> "Gunnar" == Gunnar Ritter <[EMAIL PROTECTED]> writes:
Gunnar> Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote:
>> >>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>>
Paul> Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
>>
>> >> [EMAIL PROTECTED] selects the new pax format defined
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
Paul> the existing code uses the -o option, which is [not portable]
[...]
Speaking about `o', I've just discovered that `missing' contains
some magic to strip that flag when tar fails, and retry.
It means that Roger's troubles
>>> "Carlo" == Carlo Wood <[EMAIL PROTECTED]> writes:
Carlo> I tried to upgrade to automake-1.8.3 ... but the result is
Carlo> that now I am using one monitor instead of two (*), so here
Carlo> is a report for 1.7.9 ;)
Carlo> automake-1.7.9 contains a bug in the generation of dependency
Carl
I tried to upgrade to automake-1.8.3 ... but the result is
that now I am using one monitor instead of two (*), so here
is a report for 1.7.9 ;)
automake-1.7.9 contains a bug in the generation of dependency
on 'Makefile.am'. The generated Makefile.in files contain:
$(srcdir)/Makefile.in: @MAINTAI
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> I'd say it would be useful that @SHELL@ be the most POSIX compliant
> shell that does not require any configuration code (such as
> _AS_BOURNE_COMPATIBLE) to work. CONFIG_SHELL would allow shell that
> require such extra code.
Yes, I like this i
>>> "Eric" == Eric Sunshine <[EMAIL PROTECTED]> writes:
[...]
Eric> I can submit a patch to autoconf-patches to make
Eric> Autoconf's shell selection more backward-compatible with
Eric> earlier versions of Autoconf, however this raises another
Eric> issue. My interpretation of this thread is
Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote:
> >>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>
> Paul> Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
>
> >> [EMAIL PROTECTED] selects the new pax format defined by POSIX
> >> +1003.1-2001. It supports filenames with up to 65535 char
Your e-mail to the following:
[EMAIL PROTECTED]
was infected with a virus (see below for details) and did NOT reach it's destination.
Scenarios/Incoming/virus: 'Data recognised as W32/[EMAIL PROTECTED] (Removable).'.
Scenarios/Incoming/Remove executables: 'ItemLength.GE.0'.
You can use libtool's "convenience" library feature to support this.
Automake and libtool work in conjunction to build a library which is
not installed. Unfortunately, this likely requires replacing the 3rd
party build environment.
Since Automake also supports non-recursive builds, you can create
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Also, there are moves to change the pax format (so far in an
> upward-compatible way, but you never know). Perhaps you should
> mention that "tar-pax" is intended to be the most recent version of
> the pax interchange format, not necessarily the 2001 v
Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] selects the new pax format defined by POSIX
> +1003.1-2001. It supports filenames with up to 65535 characters.
POSIX 1003.1-2001 specification does not impose any limit on
lengths of files stored in PAX interchange format.
Rega
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
Paul> Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED] selects the new pax format defined by POSIX
>> +1003.1-2001. It supports filenames with up to 65535 characters.
Paul> Hmm, where did that "65535" come from? I d
On Sun, 18 Apr 2004 16:45:00 -0500 (CDT), Bob Friesenhahn wrote:
> On Sun, 18 Apr 2004, Eric Sunshine wrote:
> > I can submit a patch to autoconf-patches to make Autoconf's shell
> > selection more backward-compatible with earlier versions of Autoconf,
> > however this raises another issue. My inte
Thanks for writing that. Some minor points:
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] selects the new pax format defined by POSIX
> +1003.1-2001. It supports filenames with up to 65535 characters.
Hmm, where did that "65535" come from? I don't know of any limit of
6
[EMAIL PROTECTED]
ERREUR : le message n'a pas été envoyé au(x) destinataire(s) car il contient un type
de fichier interdit.
ERROR: The email has not been sent to the recipient(s) because it contains a forbidden
attachment type.
Types de fichiers interdits / Forbidden file types
bat - cmd - co
17 matches
Mail list logo
