On Sat, 2022-10-29 at 01:12 +0200, Christoph Grüninger wrote:
> Thank you so much for having a deeper look and pointing out my
> problem! I unset TMPDIR and my project is working on macOS again.
It is probably strictly better if your macro preserves the existing
value of TMPDIR before resetting
On Fri, 2022-10-28 at 11:52 -0400, David A. Wheeler wrote:
> > On Oct 28, 2022, at 11:32 AM, Paul Smith wrote:
> > In this release you can see that if we can't use the TMPDIR value,
> > we fall back to a default value. I'm not sure this is correct;
> > there'
On Fri, 2022-10-28 at 09:15 +0900, suzuki toshiya wrote:
> AC_CONFIG_COMMANDS([dof_free_bit.h],
> [AS_TMPDIR([alberta])
> TMPDIR=${tmp}
>
> rm -rf ${TMPDIR}],
> [BITS=$(( ${ac_cv_sizeof_long} * 8 ))])
Oh yeah, that's it.
If you're going to remove TMPDIR you better also clear it!!
unset
On Fri, 2022-10-28 at 00:46 +0200, Christoph Grüninger wrote:
> > config.status: executing libtool commands
> > config.status: executing packageheaders commands
> > make: TMPDIR value
> > /var/folders/lr/5gw1xrv53h1b_9mjjvs2k1drgn/T//albertaiwcZfY: No
> > such file or directory
I added this
On Mon, 2022-10-17 at 14:11 +0900, suzuki toshiya wrote:
> On my macOS 21 (Monterey), /usr/bin/make is GNU make 3.81
I don't follow MacOS so I can't say what the differences are between
different versions. However, be aware that this is NOT standard GNU
make 3.81 as provided by GNU. This
On Sun, 2022-10-16 at 23:42 +0200, Christoph Grüninger wrote:
> Makefile | make -f - am--depfiles
> > make: *** fopen (temporary file): No such file or directory. Stop.
>
> Any idea what I am missing? I double-checked hat the used make has
> version 4.3.91.
You'll need to triple-check
On Sun, 2022-10-09 at 16:39 -0400, Zack Weinberg wrote:
> Paul, can I suggest that this kind of problem would be easier to
> troubleshoot if make printed the name of the temporary file that it
> could not fopen?
In the current Git version, it does do this:
... _("fopen: temporary file %s:
On Sun, 2022-10-09 at 18:33 +0200, Christoph Grüninger wrote:
> > config.status:1976: ... sed -e '/# am--include-marker/d' Makefile | make -f
> > - am--depfiles
> > make: *** fopen (temporary file): No such file or directory. Stop.
This command is asking make to read a makefile from stdin.
On Tue, 2022-02-15 at 16:59 -0600, Bob Friesenhahn wrote:
> The people who tell me it is more portable are very interested in
> targeting Microsoft Windows.
Unsurprising :).
Just to be clear, cmake can't/won't help you write programs that are
portable to Windows. If you are targeting the W32
On Tue, 2022-02-15 at 15:37 -0600, Bob Friesenhahn wrote:
> I have been told by several people (who have much more self-esteem
> than me) that a build tool called 'cmake' is far more portable than
> Autotools so maybe we should make support for 32 year old systems
> cmake's responsibility?
On Mon, 2021-01-25 at 17:48 -0500, Nick Bowler wrote:
> But for me, I want my packages to be widely portable and out-of-the-
> box compatibility with default "make" implementations, to the
> greatest extent possible, on a wide variety of real-world platforms
> is important.
I understand, but
On Tue, 2021-01-26 at 11:01 -0800, Andy Tai wrote:
> GNU Make integrates with guile. Maybe such extension can be
> done using guile for flexibility?
The problem is that hardly any standard distributions build GNU make
with Guile support enabled. If this was used basically it would end up
On Mon, 2021-01-25 at 13:27 -0700, John Calcote wrote:
> > To be honest if Automake-generated Makefile.in files only worked
> > for users with, say, sufficiently modern versions of GNU Make, I'm
> > not sure there would be any point in using Automake.
>
> I'm not sure I see your point Nick. Why
On Mon, 2021-01-25 at 09:47 -0500, Zack Weinberg wrote:
> I'm not at all familiar with Automake's internals, but the reason I
> suggested taking advantage of GNU make extensions was the potential
> for _complexity_ reduction of the generated Makefile, not
> performance.
Oh yes, there's absolutely
On Sun, 2021-01-24 at 16:26 -0700, Tom Tromey wrote:
> I think it would be good. I'm curious if it is known to be faster or
> if that's just an expectation. I'd also be very interested to learn
> which changes would make the result faster.
Speaking for myself I'm not convinced requiring GNU
On Thu, 2021-01-14 at 12:56 +0100, Sébastien Hinderer wrote:
> My question is: between LIBS and LDLIBS, which one is a build system
> supposed to honour?
"Supposed to" according to whom?
The GNU make manual, and the built-in GNU make rules, all use LDLIBS.
There is no mention of LIBS there.
On Tue, 2019-03-05 at 15:06 -0600, Eric Blake wrote:
> On 3/5/19 3:01 PM, Nicholas Clark wrote:
> > So let's say somebody from the community wanted to cut a new Autoconf
> > release. How would they go about doing it?
>
> HACKING gives a nice overview
One hurdle that people may want to keep in
On Fri, 2014-09-26 at 10:51 -0400, Steve Simmons wrote:
2) build a 'real' /bin/sh without those compiled in. This begs the
definition of 'real', but IMHO if it's not in POSIX, it shouldn't be
in 'real' /bin/sh
Ubuntu and it's derivatives have been doing this since 2006. /bin/sh on
these
On Sun, 2014-09-07 at 22:52 +0200, Bastien Chevreux wrote:
having used gcc for ages, I decided to try and play around with clang
for one of my C/C++ projects. Unfortunately, it looks as if autoconf
2.69 gets things horribly wrong with clang.
In what way? IIUC, configure has discovered that
On Sat, 2014-08-23 at 18:33 -0700, Paul Eggert wrote:
Paul Smith wrote:
It needs to be considered carefully.
How about having GNU 'make' do what GNU 'cp -u' does?
The idea is to infer filesystem timestamp resolution by looking at every
file timestamp that crosses your desk. When you
On Tue, 2014-08-26 at 18:04 +0300, Eli Zaretskii wrote:
(I don't know why Windows doesn't, because NTFS does support
millisecond resolution timestamps I believe)
Because no one wrote the code, of course.
Ah, the oldest reason in free software :-).
The main problem is that this requires
On Thu, 2014-08-21 at 13:57 -0700, Paul Eggert wrote:
David Boyce wrote:
The obvious compromise would be to change the behavior only in the
presence of the .POSIX: special target.
We should limit .POSIX to what POSIX requires. Even if the ruling
stands POSIX won't require the HP-UX
On Wed, 2013-10-30 at 05:36 -0400, Jeffrey Walton wrote:
First, time_t is supposed to be an integer or real
(http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/types.h.html).
Its hard to blame the compiler's warning system for a broken
implementation.
The ISO C standard does not
On Mon, 2013-06-03 at 13:37 -0700, Kip Warner wrote:
Another thing, I see the the libstdc++.so.6 and libgcc_s.so.1 removed
from its dependencies according to objdump, but I did note the addition
of a new one, ld-linux-x86-64.so.2. Do you think that will be a problem?
I can't think of any
I'm removing automake from this thread as I'm getting two copies of
every mail. Hope no one minds.
On Sun, 2013-06-02 at 03:06 -0400, Mike Frysinger wrote:
On Sunday 02 June 2013 01:10:36 Kip Warner wrote:
On Sat, 2013-06-01 at 23:14 -0400, Mike Frysinger wrote:
be aware that what ever
On Mon, 2013-05-20 at 09:11 -0600, Eric Blake wrote:
On 05/20/2013 09:01 AM, Paul Wise wrote:
On Mon, 2013-05-20 at 08:37 -0600, Eric Blake wrote:
I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has
On Thu, 2011-12-22 at 21:54 -0800, Paul Eggert wrote:
On 12/22/11 17:08, Karl Berry wrote:
+In the C locale, the output of GNU programs should stick to plain
+ASCII for quotation characters in messages to users: preferably 0x22
+(@samp{}) or 0x27 (@samp{'}) for both opening and closing
On Tue, 2011-12-20 at 15:44 -0800, Karl Berry wrote:
Paolo, since Paul clearly feels strongly about this, can you change the
wording to allow either one? Then we can see what rms says.
I'm afraid I don't quite understand the proposed change.
From the point of view of an implementor, which I
On Sat, 2010-06-19 at 05:05 +0200, Ralf Wildenhues wrote:
This isn't the whole truth. Posix (I don't recall which version)
requires backslash-newline to be passed as such to the shell, and GNU
make 3.81 changed semantics in this regard.
The rule is present in the 2004 POSIX spec (and of
On Sat, 2010-06-19 at 05:05 +0200, Ralf Wildenhues wrote:
This isn't the whole truth. Posix (I don't recall which version)
requires backslash-newline to be passed as such to the shell, and GNU
make 3.81 changed semantics in this regard.
The rule is present in the 2004 POSIX spec (and of
Anyone have any thoughts on this?
On Sun, 2009-08-02 at 15:56 -0400, Paul Smith wrote:
Hi all; I have a bug filed with GNU make that says:
Building GNU Make on Tru64 requires
CPPFLAGS = -D_XOPEN_SOURCE_EXTENDED -D_OSF_SOURCE
_XOPEN* is needed
Hi all; I have a bug filed with GNU make that says:
Building GNU Make on Tru64 requires
CPPFLAGS = -D_XOPEN_SOURCE_EXTENDED -D_OSF_SOURCE
_XOPEN* is needed to get the prototype for bsd_signal(), and
_OSF* to typedef u_long and friends, which is
On Thu, 2008-09-11 at 16:45 +0100, Giles Anderson wrote:
export ORAENV_ASK=NO
export ORACLE_SID=SID1
source oraenv
Not answering your question, but: please don't use this format. This
results in your configure file being egregiously and needlessly
bash-specific; it is not portable
On Thu, 2008-09-11 at 21:06 -0700, Ben Pfaff wrote:
This makes it sounds as if export VAR=VALUE were bash-specific,
but in fact this syntax is part of POSIX:
http://www.opengroup.org/onlinepubs/009695399/utilities/export.html
True, although older versions didn't have this IIRC.
And, there
On Wed, 2008-04-16 at 13:51 -0300, Sérgio Durigan Júnior wrote:
Yes, it is a bug. What we want to know is if we should append $CFLAGS
to $BASECFLAGS (i.e., BASECFLAGS=$BASECFLAGS @CFLAGS@) or use *only*
$CFLAGS when the user provides it.
By convention and practice, the former (CFLAGS are ADDED
On Mon, 2008-03-17 at 15:37 +0100, Dirk wrote:
I HAVE written something that works better than autoconf... in the
real world... that requires only a installed C compiler... and is so
easy it makes autoconf look like a project whose purpose is to harm
open source development...
Hah! Good one.
On Sun, 2008-03-16 at 15:40 +0100, Dirk wrote:
My point is that autoconf is such a bloated, self-important,
wet-script-kiddie-dream that is DOESN'T make the build process
easier...
It rather encourages people to write their own config scripts...
So the whole thing has lost its meaning...
On Sun, 2008-03-16 at 17:12 -0300, Henrique de Moraes Holschuh wrote:
On Sun, 16 Mar 2008, Paul Smith wrote:
Second, if you think you can write your own config script that will be
portable to even a small fraction of the systems that an autoconfiscated
LOL! I think you wanted to say
On Thu, 2008-02-07 at 17:24 +0200, Bernd Jendrissek wrote:
On Feb 7, 2008 5:09 PM, Jules Colding [EMAIL PROTECTED] wrote:
Wouldn't the world be a better place if the GNU Coding Standards
respected the FHS?
IMHO it would.
Perhaps, but I think the reasoning is that the common case is
On Thu, 2008-02-07 at 11:13 -0500, joe shoemaker wrote:
Does autoconf really worry about distribution, or does this belong to
Makefile.am where I just create dist target in Makefile.am?
Autoconf per se doesn't have much to do with making a distribution.
However, automake (the program that
On Thu, 2007-09-20 at 02:51 -0600, Warren Young wrote:
Maybe you can switch to Savannah's evil twin, Gna. http://gna.org/
The software I work on is GNU make. I don't think the FSF (who holds
the copyright) would be too thrilled about it moving to Gna :-).
--
My problem with all these tools is the only ones that seem to have any
serious attempts at portability so far--and by portability I include
ports to Windows that are relatively easy to install and _run well_--are
CVS and Subversion.
Of those, Savannah does not support Subversion.
So, I'm stuck
%% Harlan Stenn [EMAIL PROTECTED] writes:
hs Sometimes it's Really Hard to check for features/problems.
hs Really Really Hard.
This is especially true when cross-compiling.
I realize this is my personal bias speaking, but I would rate properly
supports cross-compiling far above checks for
%% Ralf Corsepius [EMAIL PROTECTED] writes:
rc On Thu, 2006-02-02 at 16:35 -0500, Paul Smith wrote:
%% Harlan Stenn [EMAIL PROTECTED] writes:
hs Sometimes it's Really Hard to check for features/problems.
hs Really Really Hard.
This is especially true when cross-compiling.
rc
%% Paul Eggert [EMAIL PROTECTED] writes:
pe I'm not sure why you mention setitimer as well -- what facilities
pe do you need other than sleeping?
None. But setitimer() is part of normal POSIX/SuS I think, while
nanosleep is part of the realtime extensions. So, I was wondering if
%% Howard Chu [EMAIL PROTECTED] writes:
hc The tried-and-true method for the past 20-some years has been
hc select() with no descriptor sets...
Well, of course select has its own set of portability issues. Good
point, though.
--
Hi all;
It doesn't seem that autoconf has any macros that provide for sub-second
timers. Is there any agreed-upon standard for managing this? Is
setitimer() the most portable option for sub-second timestamps? Are
there known portability issues with it?
Should I check for usleep() if setitimer
[[ I tried posting this to the libtool mailing list last week but no
responses there... I wonder if anyone here has any ideas? ]]
I have a situation where I'm constructing a filesystem image, and I need
to use the contents of that image to build new packages to be installed
in the image.
%% John W. Eaton [EMAIL PROTECTED] writes:
jwe Maybe a better place to get the current versions of these files is
jwe here:
jwe http://savannah.gnu.org/projects/config/
jwe It seems to me that instead of copying the files to the GNU ftp
jwe server (even if it could be done
%% Paul Eggert [EMAIL PROTECTED] writes:
pe The GNU FTP server has been frozen since late July; nothing new
pe has appeared on it. I don't know what the holdup is.
It's not the entire server: the server was cracked (surely you heard
about this?) and so they took off all the content until it
%% Akim Demaille [EMAIL PROTECTED] writes:
ad aclocal is to be run twice: one first time to make sure all the
ad macros that might be used are imported, so that, for instance, if
ad you use PDS_USUAL_STUFF which includes an invocation of
ad AM_GNU_GETTEXT, or AC_PROG_LIBTOOL etc. be
%% Paul Eggert [EMAIL PROTECTED] writes:
pe Have you tried autoreconf --verbose --install --force? That's what
pe Bison does. Perhaps --force is the magic that you need. Anyway,
pe the --verbose might let you debug things.
I did use --verbose and --debug, that's how I found out what's
%% Paul Eggert [EMAIL PROTECTED] writes:
pe I have installed the following patch into the Autoconf CVS. It should
pe appear in the next version of Autoconf, and it should fix your problem.
pe 2002-05-08 Paul Eggert [EMAIL PROTECTED]
pe * lib/autoconf/functions.m4
%% Tom Tromey [EMAIL PROTECTED] writes:
Paul That was correctly filled in. But, the second part of this
Paul sentence never came true; GETLOADAVG_LIBS was never added to
Paul LIBS.
ntom You need to do this part. Automake doesn't try to guess what
ntom things you might want to link
54 matches
Mail list logo
