On Wed, Jan 02, 2008 at 10:48:34PM +0100, Ralf Wildenhues wrote:
> Hello Marc,
>
> Thanks for the report.
>
> * Marc Espie wrote on Thu, Dec 27, 2007 at 05:29:37PM CET:
> > On Thu, Dec 27, 2007 at 05:25:56PM +0100, Marc Espie wrote:
> > > the mkdir -p macro arbit
And yet another problematic package, jpilot fails to install correctly
when built in parallel mode for the same reason.
Even if detecting OpenBSD is not easy, I don't understand why this test
is hardcoded.
In general, most autoconf/automake tests DO set a cache entry, and you
can later rely on th
On Thu, Dec 27, 2007 at 05:25:56PM +0100, Marc Espie wrote:
> the mkdir -p macro arbitrarily restricts itself to GNU mkdir by passing
> it a --version.
>
> This is a bit offensive. On OpenBSD, this particular issue does not exist.
> It was fixed 8 years ago, published as OpenB
the mkdir -p macro arbitrarily restricts itself to GNU mkdir by passing
it a --version.
This is a bit offensive. On OpenBSD, this particular issue does not exist.
It was fixed 8 years ago, published as OpenBSD 2.4, and all newer versions
are not affected.
Could we get an OS test and use mkdir on
far as I could tell @VTEXI@ is always intended to be built in
the source directory, so the following patch allows it to be
correctly built with any make:
2000-12-15 Marc Espie <[EMAIL PROTECTED]>
* automake.in (handle_texinfo): Make path of $vtexi explicit in
depen
There is a small problem with automake-1.4 that is no longer present
in the development reasons.
There is a weird interaction with some versions of ksh that make the
generated recursive clean rules fail. Namely, the error from within
the loop propagates outside the loop and makes the whole target
