Hi Ben,
* Ben Pfaff wrote on Tue, Aug 19, 2008 at 07:15:36AM CEST:
* bin/autom4te.in (handle_output): Atomically replace the output
file, in most circumstances, instead of overwriting it, to avoid
leaving a partially written output file.
I sent this revised patch to
Ralf Wildenhues Ralf.Wildenhues at gmx.de writes:
(better: I can't reproduce them with that, with a number of shells),
which means the number of currently known-problematic places in Autoconf
code is quite small, I found one in status.m4 and one in the test suite.
Thanks for the audit.
Hi Eric,
* Eric Blake wrote on Tue, Aug 19, 2008 at 10:52:46PM CEST:
Ralf Wildenhues Ralf.Wildenhues at gmx.de writes:
I'm pretty sure that any remaining test failure I'm seeing are not
introduced by this patch, so if you are ok with it I'll apply.
Any help I can offer on tracking down
Ralf Wildenhues Ralf.Wildenhues at gmx.de writes:
Any help I can offer on tracking down the (unrelated) AS_IF failures?
Not sure. See below. I recently updated this system to Debian lenny, I
kind of think that may be one cause (or exposure reason).
Hmmm. This looks suspicious:
Ralf Wildenhues [EMAIL PROTECTED] wrote:
* Jim Meyering wrote on Mon, Aug 18, 2008 at 11:57:45PM CEST:
Ralf Wildenhues [EMAIL PROTECTED] wrote:
I think we can factor it into a simpler testcase. I just tried this:
$ sh -c 'if test `sleep 5; echo hi` = hi ; then echo yes; fi'
and found
Ralf Wildenhues [EMAIL PROTECTED] writes:
I'm stumbling over the testsuite failure though (and wondering
slightly if this can in any way be a destabilizing change).
On what kind of a system was this testsuite failure observed? I
would like to fix the problem before we proceed. I did test,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Peter O'Gorman on 8/17/2008 4:31 PM:
In the majority of cases there are no problems building universal
binaries in this manner. But there are enough cases where it does not
build, or where it builds but has problems for some
Hi Ralf,
Well, what I mean is, what if a library libfoo is needed to build
program bar. Autotools tries to find the library on the system
(e.g.check /usr/lib, and so on). But if it is not found, then the
program will not compile and configure gives an error, right. Now, if
libfoo is not fond on
Robert Rehammar wrote:
Well, what I mean is, what if a library libfoo is needed to build
program bar. Autotools tries to find the library on the system
(e.g.check /usr/lib, and so on). But if it is not found, then the
program will not compile and configure gives an error, right. Now, if
* Robert Rehammar wrote on Tue, Aug 19, 2008 at 08:08:32AM CEST:
So the next thing would then be for configure to ask apt to download and
install libfoo, to meet the dependency. This way autotools would
integrate with (e.g.) apt to make installations more smooth. This would
save the user the
Ralf Wildenhues wrote:
If the dependencies are already listed in apt's database, then 'apt-get
build-dep libfoo' should be all you ever need. If not, then I don't see
how Autoconf can behave better than it does now: the mapping of software
given as source to packaging names is still quite
On Tue, 2008-08-19 at 08:57 +0200, Ralf Wildenhues wrote:
So if you like, a good way out would be this, in pseudo-code:
if $missing_libfoo; then
AC_MSG_ERROR([This package needs $libfoo. Please tell your system
administrator to `apt-get build-dep $PACKAGE])
fi
with possibly
Robert Rehammar wrote:
Well, what I mean is, what if a library libfoo is needed to build
program bar. Autotools tries to find the library on the system
(e.g.check /usr/lib, and so on). But if it is not found, then the
program will not compile and configure gives an error, right. Now, if
Robert Rehammar [EMAIL PROTECTED] writes:
I am wondering if there is any module to hook up autotools with the
apt package system of e.g. Debian and Ubuntu? Wouldn't this be pretty
cool thing. It would even be possible for such a module to call aptitude
search and download the available
Hello All,
I'd like to know few things about the dir layout of autotools as i am
new to the software.
how can make put my executables into a seperate dir than the src/ dir
after compilation? What do i have to change, bindir variable? And how?
is there any command/macros for configure.ac to put
On Tue, Aug 19, 2008 at 03:24, Erik de Castro Lopo [EMAIL PROTECTED]wrote:
Robert Rehammar wrote:
This way autotools would
integrate with (e.g.) apt to make installations more smooth. This would
save the user the work to download and install all packages that bar
depends on and that
Allan Clark wrote:
ugh, maintaining that list could suck, but this is the
possibility that this kind of step takes in a way that doesn't put the
maintenance burden onto Autoconf's shoulders.
My suggestion was intended to put the burden of maintaining this
on the shoulders of whoever maintains
* Erik de Castro Lopo wrote on Tue, Aug 19, 2008 at 08:42:53PM CEST:
Allan Clark wrote:
ugh, maintaining that list could suck, but this is the
possibility that this kind of step takes in a way that doesn't put the
maintenance burden onto Autoconf's shoulders.
My suggestion was intended
On Tue, 19 Aug 2008, Ralf Wildenhues wrote:
IMVHO any kind of repetition of knowledge encoded in rpm and apt
(or system vendor X package) databases is not tolerable, if it needs to
be hand-maintained in any way. It's just too much data, getting out of
date, and too many distributions.
I don't
Hi Bob,
* Bob Friesenhahn wrote on Tue, Aug 19, 2008 at 11:14:44PM CEST:
It seems that the world would be a simpler place if the world could
standardize on just one distribution such as the one called Windows
Vista. Then we would not need Autoconf.
Yes. Wanna turn this paragraph into a
On Tue, Aug 19, 2008 at 17:14, Bob Friesenhahn [EMAIL PROTECTED]
wrote:
On Tue, 19 Aug 2008, Ralf Wildenhues wrote:
IMVHO any kind of repetition of knowledge encoded in rpm and apt
(or system vendor X package) databases is not tolerable, if it needs to
be hand-maintained in any way. It's
On Tue, 19 Aug 2008, Allan Clark wrote:
Heh. Jokes aside, I figured there's a good chance that the same project
(ie http://freshmeat.net/projects/{PROJECT} or http://{PROJECT}.sf.net/)
provides the same deliverables cross-platform. For example, the libz on
Solaris, Redhat, UNIX, and BeOS
On Tue, Aug 19, 2008 at 17:37, Bob Friesenhahn [EMAIL PROTECTED]
wrote:
On Tue, 19 Aug 2008, Allan Clark wrote:
Heh. Jokes aside, I figured there's a good chance that the same project
(ie
http://freshmeat.net/projects/{PROJECT}http://freshmeat.net/projects/%7BPROJECT%7Dor
http://
On Tue, 19 Aug 2008, Allan Clark wrote:
I therefore urge you to reconsider using existing resources for more common
cases rather than serial dependencies on new, undiscovered data and 100%
coverage which might be too difficult to reach.
You are optimizing the special case where dependencies
Bob Friesenhahn wrote:
On Tue, 19 Aug 2008, Allan Clark wrote:
I therefore urge you to reconsider using existing resources for more
common
cases rather than serial dependencies on new, undiscovered data and 100%
coverage which might be too difficult to reach.
You are optimizing the special
On Tue, 2008-08-19 at 16:14 -0500, Bob Friesenhahn wrote:
On Tue, 19 Aug 2008, Ralf Wildenhues wrote:
IMVHO any kind of repetition of knowledge encoded in rpm and apt
(or system vendor X package) databases is not tolerable, if it needs to
be hand-maintained in any way. It's just too much
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Peter O'Gorman on 8/17/2008 4:31 PM:
In the majority of cases there are no problems building universal
binaries in this manner. But there are enough cases where it does not
build, or where it builds but has problems for some
I reported this to the gnome-evolution folks who suggested that it was
really an autoconf problem.
I've just started following evo and friends in svn/trunk. One thing
I've noticed is that small changes in one module will trigger almost
full rebuilds in the remaining ones (e.g., a small change
Hello,
Ive got this message while compiling fftw with icc 3.1.038 on opensuse
11:
configure: WARNING: limits.h: present but cannot be compiled
configure: WARNING: limits.h: check for missing prerequisite headers?
configure: WARNING: limits.h: proceeding with the preprocessor's result
configure:
Hello David,
* David Ronis wrote on Mon, Aug 18, 2008 at 03:26:26AM CEST:
I've just started following evo and friends in svn/trunk. One thing
I've noticed is that small changes in one module will trigger almost
full rebuilds in the remaining ones (e.g., a small change in eds leads
to most
Hi Ralph,
Thanks for the reply. See below.
On Tue, 2008-08-19 at 22:50 +0200, Ralf Wildenhues wrote:
Hello David,
* David Ronis wrote on Mon, Aug 18, 2008 at 03:26:26AM CEST:
I've just started following evo and friends in svn/trunk. One thing
I've noticed is that small changes in one
David Ronis [EMAIL PROTECTED] writes:
Perhaps I wasn't clear enough. Say I have 2 projects,
evolution-data-server and evolution, where evolution depends on the
latter. Running make install in e-d-s generates a large number of
libraries and .h files that evolution depends on (as do other
32 matches
Mail list logo
