On Thu, Apr 24, 2025 at 01:36:23PM +0200, Jose E. Marchesi wrote:
> While upstreaming the Algol 68 autoconf support it was pointed out that the
> shell variable A68 shall be renamed to A68C and that the macro AC_PROG_A68
> shall be renamed to AC_PROG_A68C. This is to be more consistent to the
> su
On 2024-10-12 06:29, Michael Pratt via Patches for Automake wrote:
> When gnulib-tool or a bootstrap script uses the option --local-dir,
> include the "modules" files in a release with DIST_COMMON. Otherwise,
> these source files are present in checkouts but not in distribution.
I agree that missi
On 2023-11-28 16:06, Karl Berry wrote:
> Hi Ross - you sent a change to automake-patches back in February 2017.
> Sorry for the absurdly delayed reply.
>
> https://lists.gnu.org/archive/html/automake-patches/2017-02/msg1.html
>
> Instead of only accepting comment lines that start with
On 31/08/2023, Karl Berry wrote:
> Hi Bogdan,
>
> In reference to:
> https://lists.gnu.org/archive/html/automake/2023-07/msg7.html.
>
> Thanks much!
>
> Since it's Autoconf 2.70 that started using the parameter, I've
> bumped the required value.
>
> I don't think we should requ
On 14/01/2023, Zack Weinberg wrote:
> On Sat, Jan 14, 2023, at 7:18 PM, Mike Frysinger wrote:
>> Rather than assume such coarse delays, re-use existing logic for
>> probing the current filesystem resolution. This speeds up the
>> testsuite significantly.>
[...]
> No objection to this patch in its
On 2023-01-04, Mike Frysinger wrote:
[...]
> dmake is one implementation that fails, and your suggestion doesn't work
> :/.
> $ dmake foo/bar.o
> dmake: Error: -- Incomplete macro expression [)' b='$(at_f:.o=)'; test
> x"$$a.o" = x"$(@F)" || a=$$b;\
> echo $$a]
It might also be w
On 2023-01-04, Mike Frysinger wrote:
> On 04 Jan 2023 21:10, Nick Bowler wrote:
[...]
>> maybe something like:
>>
>> % cat >Makefile <<'EOF'
>> at_f = $(@F)
>> foo/bar.o:
>> a='$(@F:.o=)' b='$(at_f:.o=)'; test x&
On 2023-01-03, Mike Frysinger wrote:
> The echo|sed is used to split the dirname & filename so it can insert
> $(DEPDIR) in the middle, and then chop the trailing object suffix. In
> the generic case, %OBJ% is $@, so we can leverage the POSIX vars $(@D)
> and $(@F) to do the pathname splitting an
If you expand AM_INIT_AUTOMAKE more than once with options, automake
currently barfs on the resulting m4 traces with a less-than-helpful
assertion failure ("global options already processed"). This also
prompts users to report bugs against Automake, when the actual
problem is with their autoconf i
On 2020-10-28, Zack Weinberg wrote:
> On Wed, Oct 28, 2020 at 2:16 PM Nick Bowler wrote:
>> On 2020-10-28, H.J. Lu wrote:
>> > GCC introduced some time ago option -flto=jobserver in order to use the
>> > GNU Make jobserver when parallelising LTO builds. It is actuall
On 2020-10-28, H.J. Lu wrote:
> GCC introduced some time ago option -flto=jobserver in order to use the
> GNU Make jobserver when parallelising LTO builds. It is actually a
> similar "recursive make". When doing a recursive make, you need to
> place a '+' character at the beginning of the recipe
On 2020-04-13, Paul Eggert wrote:
> I just checked, and GNU Make uses high-resolution file timestamps when
> available, and considers a file to be up-to-date if it has exactly the same
> timestamp as its dependency. I suspect that this is because Makefile rules
> like
> this:
>
> a: b
> cp -
On 7/21/18, Ben Elliston wrote:
> This patch silences a warning from Shellcheck about using old-style
> `...` command substitutions.
[...]
> commit 4d35c7aae97234bf055519075ef03cd4090a1dfc
> Author: Ben Elliston
> Date: Sun Jul 22 08:22:44 2018 +1000
>
> * missing: Use $(..) command substit
d this?
The test appears to have been defective ever since it was introduced
almost 10 years ago. At this point, it may be better to simply remove
the dead code entirely unless this is known to fix a real problem.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
nvironment for testing but
never managed to get past the /dev/null problems described on
the comp.os.msdos.djgpp newsgroup:
Subject: Re: Reading /dev/null seems broken.
Message-ID:
https://groups.google.com/forum/?fromgroups=#!msg/comp.os.msdos.djgpp/okhH1hvBXDM/ugOABoho1V8J
Cheers,
-
On 2013-01-13, Stefano Lattarini wrote:
> On 01/13/2013 09:01 PM, Nick Bowler wrote:
>> +dnl Automatically invoke AM_PROG_CC_C_O as necessary. Since AC_PROG_CC is
>> +dnl usually called after AM_INIT_AUTOMAKE, we arrange for the test to be
>> +dnl done later by AC_CONFIG_C
ty. It's unclear to me why
my earlier suggestion (using AC_CONFIG_COMMANDS_PRE to expand
AM_PROG_CC_C_O) was inadequate. This would also require no changes
to autoconf, and we would not need to deprecate AM_PROG_CC_C_O, so
no backwards compatibility hacks are required.
These patches no longer appl
If AM_PROG_CC_C_O is expanded multiple times, and the compiler does not
support -c and -o together, each expansion of the macro will prepend
the compile script to CC. This can result in the compile script
invoking the compile script, which at best pointless and silly.
Fortunately, there does not a
If subdir-objects is made the default Automake behaviour, packages
will need to add AM_PROG_CC_C_O to their configure.ac. Instead of
that, let's just make the functionality provided by AM_PROG_CC_C_O
mandatory for C projects, and have Automake automatically call it
as required.
This change should
one installed version.
Furthermore, the test itself can be simplified: Just run autom4te
-Werror -Wwhatever on empty input (/dev/null will work). For example:
autom4te -Werror -Wno-m4require-without-m4defun /dev/null
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
On 2012-11-02 10:46 +0100, Stefano Lattarini wrote:
> On 10/23/2012 12:59 AM, Nick Bowler wrote:
> > 4) I get a bunch of new warnings from aclocal, of the form:
> >
> > configure.ac:42: warning: DX_EXPORTED_SH is m4_require'd but not
> > m4_defun'd
>
(as it requires duplicating information for no
benefit). Looking at the history, this has been the case for almost
10 years now.
For these reasons, I removed it from all of my packages a while ago
(so I get a gratuitous warning from libtoolize: oh well). Unless the
new macro fixes all of these problems, I'm afraid it will suffer a
similar fate. But maybe, just maybe, AC_CONFIG_MACRO_DIRS will gain
traction where AC_CONFIG_MACRO_DIR never did...
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
. So, if the
> +@code{dist-hook} wants to modify the content of an existing file
> +in the distribution directory, it should explicitly ensure to make
> +it readable first:
writable
I also would drop the words "ensure to".
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
goes
above and beyond what Automake provides. The exception to this is
during initial bootstrap after checkout from git, which must write to
srcdir for obvious reasons. (Aside: I just tested this and discovered
that there was a source file missing from the distribution that
distcheck didn't notice because only maintainer-clean builds failed.
Oops!)
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
On 2012-02-24 20:25 +0100, Stefano Lattarini wrote:
> On 02/24/2012 07:34 PM, Nick Bowler wrote:
> >
> > On 2012-02-24 19:19 +0100, Stefano Lattarini wrote:
> >>
> >> But it's the package that expects its distributed files to be writable
> >> that
On 2012-02-24 12:10 -0700, Eric Blake wrote:
> On 02/24/2012 11:34 AM, Nick Bowler wrote:
> >> But it's the package that expects its distributed files to be writable
> >> that is assuming too much; if such package wants its expectation to
> >> safely hold, it sh
On 2012-02-24 19:19 +0100, Stefano Lattarini wrote:
> On 02/24/2012 06:53 PM, Nick Bowler wrote:
> > On 2012-02-24 18:37 +0100, Stefano Lattarini wrote:
> > [...]
> >> On 02/24/2012 08:09 AM, Nick Bowler wrote:
> >>> Automake should at least add user write permi
On 2012-02-24 18:37 +0100, Stefano Lattarini wrote:
[...]
> On 02/24/2012 08:09 AM, Nick Bowler wrote:
> > Automake should at least add user write permissions to all files in
> > distdir prior to running dist-hook (and hence prior to generating the
> > distribution tarball
installed
I've tested this on my project, and now distcheck fails when I revert my
uninstall-local rule. It's perhaps a bit unfortunate that
make infodir='${prefix}/somewhere_else' distcheck
no longer works, but I agree that it seems non-trivial to make that
w
ts which have multiple commands. It's
not that interesting to see "GEN foo.bar" five times in a row.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
On 2010-11-04 22:28 +0100, Stefano Lattarini wrote:
> On Thursday 04 November 2010, Nick Bowler wrote:
> > On 2010-11-04 20:47 +0100, Stefano Lattarini wrote:
> > > +AC_DEFUN([MY_DEFUN], [m4_apply([AC_DEFUN], [$1], [$2])])
> >
> > This is insuf
On 2010-11-04 20:47 +0100, Stefano Lattarini wrote:
> On Thursday 28 October 2010, Stefano Lattarini wrote:
> > On Wednesday 27 October 2010, Nick Bowler wrote:
> > > On 2010-10-23 15:23 +0200, Stefano Lattarini wrote:
> > > > So I think your first problem is "ju
32 matches
Mail list logo
