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 Sun, 24 Jan 2021, Zack Weinberg wrote:
On Sun, Jan 24, 2021 at 7:27 PM Bob Friesenhahn
wrote:
AC_SUBST([CONFIGURE_DEPENDENCIES],["$CONFIGURE_DEPENDENCIES \$(top_srcdir)/ChangeLog
\$(top_srcdir)/version.sh"])
Why did you write it like this instead of
CONFIGURE_DEPENDENCIES = $(top_srcdi
On Sun, 24 Jan 2021, Paul Eggert wrote:
On 1/23/21 4:06 PM, Bob Friesenhahn wrote:
A tiny fork/exec is not a big deal.
It is indeed not a big deal. That being said, one can optimize away GNU
make's fork and exec by using "@:" instead of "@true".
At the moment it is a big deal for me becau
On Mon, Jan 25, 2021 at 8:38 AM Paul Smith wrote:
> 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
On Mon, Jan 25, 2021 at 9:52 AM Bob Friesenhahn
wrote:
> At the moment it is a big deal for me because the locking prototol
> that Autoconf/Automake is using does not work with NFS mounts for
> Illumos-derived systems when the client is also an Illumos-derived
> system, because Illumos failed to s
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 1/4/21 5:42 PM, Zack Weinberg wrote:
I think what this project actually wants, at least for right now, is
to not run autopoint. To make that possible again, I have demoted the
"AM_GNU_GETTEXT is used, but not
AM_GNU_GETTEXT_VERSION" message to a warning. The fix is on
development trunk as co
On Mon, Jan 25, 2021 at 10:23 AM Eli Schwartz wrote:
>
> On 1/4/21 5:42 PM, Zack Weinberg wrote:
> > I think what this project actually wants, at least for right now, is
> > to not run autopoint. To make that possible again, I have demoted the
> > "AM_GNU_GETTEXT is used, but not
> > AM_GNU_GETTE
Zack, thanks for the interesting analysis.
In the *short* term, I think “create a CI system” is the critical first step.
Since the autotools are all about supporting many platforms, if possible that
infrastructure should support VMs with many different targets (many Linuxes,
MacOS, Windows, som
On 1/25/21 10:29 AM, Zack Weinberg wrote:
On Mon, Jan 25, 2021 at 10:23 AM Eli Schwartz wrote:
On 1/4/21 5:42 PM, Zack Weinberg wrote:
I think what this project actually wants, at least for right now, is
to not run autopoint. To make that possible again, I have demoted the
"AM_GNU_GETTEXT is
On Mon, 25 Jan 2021, Zack Weinberg wrote:
Automake "just" calls Perl's 'flock' built-in (see 'sub lock' in
Automake/XFile.pm) (this code is copied into Autoconf under the
Autom4te:: namespace). It would be relatively straightforward to
teach it to try 'fcntl(F_SETLKW, ...)' if that fails. Do y
On 2021-01-25, 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.
> For instance, this generated rule from one of m
On Mon, Jan 25, 2021 at 12:26 PM Nick Bowler wrote:
> On 2021-01-25, 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
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, 25 Jan 2021, Zack Weinberg wrote:
and enable Make to bypass the shell altogether. Might be worth
benchmarking on a big program. Has to be an executable, not a
library, though; for libraries, the overhead of the libtool script is
going to dominate.
As a reminder, a former Automake mai
On Mon, 25 Jan 2021, 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 use Automake? Because I'd m
On 1/25/21 5:37 AM, Paul Smith wrote:
The only thing that would make much of a performance difference, I
think, is if we are able to replace lots of shell invocations with
built-in make functions like wildcard, if, etc.
One other thing could be a significant performance win: if we could use
GN
On Mon, 25 Jan 2021, Paul Eggert wrote:
On 1/25/21 5:37 AM, Paul Smith wrote:
The only thing that would make much of a performance difference, I
think, is if we are able to replace lots of shell invocations with
built-in make functions like wildcard, if, etc.
One other thing could be a signif
On 2021-01-25, John Calcote wrote:
> On Mon, Jan 25, 2021 at 12:26 PM Nick Bowler wrote:
>> On 2021-01-25, 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_
On Mon, Jan 25, 2021 at 02:10:01PM -0800, Paul Eggert wrote:
> On 1/25/21 5:37 AM, Paul Smith wrote:
> > The only thing that would make much of a performance difference, I
> > think, is if we are able to replace lots of shell invocations with
> > built-in make functions like wildcard, if, etc.
>
>
On Mon, Jan 25, 2021 at 10:59 PM Gavin Smith wrote:
> storing the value that should be in CC in the file CC.conf. Does this
> work or does GNU make have other ways of doing this? (It would be
> better if it could be done without communicating via files.) Is there
> any way to set a Makefile var
On 1/25/21 2:59 PM, Gavin Smith wrote:
Does this
work or does GNU make have other ways of doing this? (It would be
better if it could be done without communicating via files.) Is there
any way to set a Makefile variable from within a rule and then depend upon
that variable being set in other ru
22 matches
Mail list logo
