GNU bug report logs - #19579
Long lines, short awk

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19579 in the body.
You can then email your comments to 19579 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
To: bug-automake <at> gnu.org
Subject: Long lines, short awk
Date: Tue, 13 Jan 2015 01:01:44 -0500

Hello list,

I am building a source package, prepared with Automake 1.15, on HP-UX.
While running the configure script, I get

    [...]
    config.status: creating include/Makefile
    config.status: creating scripts/Makefile
    config.status: creating src/Makefile
    config.status: creating src/lib/Makefile
    awk: Input line         -rm -rf ../../src/l cannot be longer than 3,000 bytes.
     The input line number is 21137.
     The source line number is 235.
    config.status: error: could not create src/lib/Makefile

It so happens that src/lib/Makefile covers a large number of source
files, spread out across many directories. Line 21137 of Makefile.in is
the "-rm -rf" line shown below:

    distclean: distclean-am
            -rm -rf ../../src/lib/libobj/$(DEPDIR) foo/bar/$(DEPDIR) foo/baz/$(DEPDIR) ...

The line includes every single subdir-objects subdirectory known to the
makefile, and is well over 15kB long. The maintainer-clean target also
has an identical line.

I recognize that the usual thing to do here is specify e.g. AWK=gawk,
but other sections of the makefile (e.g. clean-libtool target) avoid
this issue altogether by specifying a series of short "rm" commands
instead of a single giant invocation. (Moreover, even if $AWK didn't
have a line-length limitation, the shell could still balk with an
"Argument list too long" error.) IMO, it is better to have the distclean
and maintainer-clean targets follow this same approach.


--Daniel


-- 
Daniel Richard G. || skunk <at> iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.

Message #8 received at 19579 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Cc: 19579 <at> debbugs.gnu.org
Subject: Re: Long lines, short awk
Date: Tue,  8 Feb 2022 04:03:07 +0000 (UTC)

On Tue, 13 Jan 2015 01:01:44 -0500, Daniel Richard G. wrote:
> I am building a source package, prepared with Automake 1.15, on HP-UX.
> While running the configure script, I get
>
>     [...]
>     config.status: creating include/Makefile
>     config.status: creating scripts/Makefile
>     config.status: creating src/Makefile
>     config.status: creating src/lib/Makefile
>     awk: Input line         -rm -rf ../../src/l cannot be longer than 3,000 bytes.
>      The input line number is 21137.
>      The source line number is 235.
>     config.status: error: could not create src/lib/Makefile
>
> It so happens that src/lib/Makefile covers a large number of source
> files, spread out across many directories. Line 21137 of Makefile.in is
> the "-rm -rf" line shown below:
>
>     distclean: distclean-am
>             -rm -rf ../../src/lib/libobj/$(DEPDIR) foo/bar/$(DEPDIR) foo/baz/$(DEPDIR) ...
>
> The line includes every single subdir-objects subdirectory known to the
> makefile, and is well over 15kB long. The maintainer-clean target also
> has an identical line.

can you provide an example that reproduces the issue ?  or link to the package
you're working on (assuming it's OSS) ?  i checked my own projects and it didn't
create a single line, it generated a bunch of independent rm commands.  i looked
through the automake source and couldn't quickly identify something that would
explain the behavior you're seeing.
-mike

Message #13 received at 19579 <at> debbugs.gnu.org (full text, mbox):

From: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
To: "Mike Frysinger" <vapier <at> gentoo.org>
Cc: 19579 <at> debbugs.gnu.org
Subject: Re: Long lines, short awk
Date: Mon, 14 Feb 2022 01:14:54 -0500

Hello Mike,

On Mon, 2022 Feb  7 23:03-05:00, Mike Frysinger wrote:
>
> can you provide an example that reproduces the issue ?  or link to the
> package you're working on (assuming it's OSS) ?  i checked my own
> projects and it didn't create a single line, it generated a bunch of
> independent rm commands.  i looked through the automake source and
> couldn't quickly identify something that would explain the behavior
> you're seeing.

I am currently using Automake 1.16.3, which no longer exhibits the
issue originally described. As far as I can tell, this was fixed as a
side effect of Git commit 08849db8, made just ten days before my
initial report.


--Daniel


-- 
Daniel Richard G. || skunk <at> iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.

Message #18 received at 19579-done <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Cc: 19579-done <at> debbugs.gnu.org
Subject: Re: Long lines, short awk
Date: Mon, 14 Feb 2022 07:12:38 -0500

[Message part 1 (text/plain, inline)]

On 14 Feb 2022 01:14, Daniel Richard G. wrote:
> On Mon, 2022 Feb  7 23:03-05:00, Mike Frysinger wrote:
> > can you provide an example that reproduces the issue ?  or link to the
> > package you're working on (assuming it's OSS) ?  i checked my own
> > projects and it didn't create a single line, it generated a bunch of
> > independent rm commands.  i looked through the automake source and
> > couldn't quickly identify something that would explain the behavior
> > you're seeing.
> 
> I am currently using Automake 1.16.3, which no longer exhibits the
> issue originally described. As far as I can tell, this was fixed as a
> side effect of Git commit 08849db8, made just ten days before my
> initial report.

ok, thanks for checking
-mike

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.