On Fri, 2025-02-21 at 18:12 -0600, Jacob Bachmeyer wrote:
> Does GNU Make not recognize rules that declare dependencies of
> makefiles? Presumably the makefile could include a rule:
> Makefile: CMakefile
> $(CMAKE) ...
You're 100% right, of course. I clearly had not had my morning tea
whe
On Fri, 2025-02-21 at 16:53 +0100, Ben Boeckel wrote:
> > I think it should be possible to preserve the per-directory entry
> > points, now that POSIX make supports "include".
>
> Does it preserve the "defer actually including until its associated
> recipe is up-to-date" behavior? If my memory ser
On Fri, 2025-02-21 at 12:26 +0100, Ben Boeckel wrote:
> CMake's Makefile implementation can support it; it supports Fortran
> modules after all. However, `ninja` support is far easier as it (in
> CMake's implementation) has a single graph for the entire build. The
> Makefiles generator is a 3-level
On Tue, 2025-02-18 at 16:32 -0500, Zack Weinberg wrote:
> 2) Besides an "is this feature available" probe, I don't know if any
> support for C++ 2020 modules is even *necessary*, because I don't
> know how they work. If any other changes are necessary, they would
> probably need to happen
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 it
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&#x
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 TMPDIR
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 ch
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 instanc
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 t
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: %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. When
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 sy
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?
That
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 stand
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
requir
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 us
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 make
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.
So,
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 min
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 sys
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 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 requ
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 ev
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
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 r
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 rea
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 eve
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 top
Does anyone have a macro that will correctly determine when -rdynamic
and/or -Wl,--export-dynamic can be used? I'm not using libtool but I'd
like my application to be built such that functions in it can be invoked
by dynamically loaded objects.
I saw http://www.mail-archive.com/autoconf@gnu.org/m
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 cou
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
>
&g
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 u
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, th
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 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 A
Since your last post seemed to be a bit more willing to engage in a
dialog, I'll send this then I'm done. Some of these points have been
made already but maybe some concrete examples will help.
You have two misconceptions which are contributing to your frustration,
I think: the first and largest
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 o
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
>
&
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 mean
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 par
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
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
%% 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 i
%% 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
%% 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.
--
-
%% 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
setitim
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. For
%% 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
%% "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
%% 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
%% Soren A <[EMAIL PROTECTED]> writes:
>> I'm using autoconf 2.54 / automake 1.7 / gettext 0.11.5.
sa> I am not clear on what package you, Paul, are trying to build.
GNU make. For the purposes of this subject it doesn't matter, though.
sa> I have never heard of `autopoint' before and wo
%% 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 o
%% 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 (AC_FUNC_S
%% 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
58 matches
Mail list logo
