Problem building "master" version...

[Kenny McCormack]

Sometime ago (September 1st or thereabouts), I downloaded the "master"
branch of GAWK from Savanna. I was looking for something else at the time
(since Andy always recommends using the master branch if possible - if you
are looking for new features not yet in the "regular" releases). Anyway, I
never tried to actually build it until now.

Today, I did ./configure and it worked fine. Then I did "make" and it
aborted almost immediately, with these error messages:

(pts/6:726) % make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/pi/Build/gawk_master/gawk/missing aclocal-1.15 -I m4
/home/pi/Build/gawk_master/gawk/missing: line 81: aclocal-1.15: command not found
WARNING: 'aclocal-1.15' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
<http://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<http://www.gnu.org/software/autoconf>
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
Makefile:597: recipe for target 'aclocal.m4' failed
make: *** [aclocal.m4] Error 127
(pts/6:727) %

--

"This ain't my first time at the rodeo"

is a line from the movie, Mommie Dearest, said by Joan Crawford at a board meeting.

[Kaz Kylheku]

On 2016-10-14, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> Makefile:597: recipe for target 'aclocal.m4' failed
> make: *** [aclocal.m4] Error 127
> (pts/6:727) %

Just today R. Weikusat in comp.unix.programmer reported having this
sort of problem with some unspecified project pulled out of some
git repo.

I pointed to this: an answer I gave on StackOverflow (June 2016) to the
question

"How to overcome “'aclocal-1.15' is missing on your system”
warning when compiling?"

http://stackoverflow.com/questions/33278928/how-to-overcome-aclocal-1-15-is-missing-on-your-system-warning-when-compilin/37669184

In my answer I used ... GNU Awk as the example! :)

(The answer covers only getting "make gawk" working; I didn't care about
the other targets like extlib so I didn't "recurse the fix" into that
subdirectory.)

[Kenny McCormack]

In article <201610141...@kylheku.com>,

Kaz Kylheku <221-50...@kylheku.com> wrote:
>On 2016-10-14, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> Makefile:597: recipe for target 'aclocal.m4' failed
>> make: *** [aclocal.m4] Error 127
>> (pts/6:727) %
>
>Just today R. Weikusat in comp.unix.programmer reported having this
>sort of problem with some unspecified project pulled out of some
>git repo.
>
>I pointed to this: an answer I gave on StackOverflow (June 2016) to the
>question
>
> "How to overcome “'aclocal-1.15' is missing on your system”
> warning when compiling?"
>
>http://stackoverflow.com/questions/33278928/how-to-overcome-aclocal-1-15-is-missing-on-your-system-warning-when-compilin/37669184

Yes. I am now able to compile (master branch) gawk, via "make gawk".

Here is the version output:

$ ./gawk -W version
GNU Awk 4.1.60, API: 1.2
Copyright (C) 1989, 1991-2016 Free Software Foundation.
(etc)
$

But, alas, x = @/foo/
still doesn't work. So, I'm still wondering which version(s) had that
feature in, before they took it out.

BTW, I agree with you that it is stupid to take it out, once it is in.
Put up a warning, sure - saying "This doesn't work very well, don't depend
on it, you have been warned, etc, etc" , but why remove it?

--
Kenny, I'll ask you to stop using quotes of mine as taglines.

- Rick C Hodgin -

[sean]

Kaz Kylheku wrote:
> I pointed to this: an answer I gave on StackOverflow (June 2016) to the
> question
>
> "How to overcome “'aclocal-1.15' is missing on your system”
> warning when compiling?"
>
> http://stackoverflow.com/questions/33278928/how-to-overcome-aclocal-1-15-is-missing-on-your-system-warning-when-compilin/37669184

That's the post I've found a few times to get be past a few autotools
problems myself.

I get past the problems by running autoreconf -f -i

BTW, is gawk that active of a project where building from source is
common, or is it more of a development efforts to patch things?

Thanks!

[Kaz Kylheku]

This commit removes it:

commit 9907a598dca8f129422c42f8c4fa3b4e2c988221
Author: Arnold D. Robbins <arn...@skeeve.com>
Date: Wed Aug 3 21:23:22 2016 +0300

Remove typed regexps until they can be done correctly.

This one, its parent, still has it:

commit 58cd470fe6b37ff2b62f5bc5b8cedf19be04fc63
Merge: 3a45bdf 4f068c0
Author: Arnold D. Robbins <arn...@skeeve.com>
Date: Tue Aug 2 20:52:33 2016 +0300

Merge branch 'gawk-4.1-stable'

The NEWS file was updated to inform about the regexp literals in
this commit:

commit 5603143c58035b91f91ee31ab548b9b996156760
Author: Arnold D. Robbins <arn...@skeeve.com>
Date: Tue May 12 14:52:43 2015 +0300

Update NEWS for typed regexp constants and typeof.

They were implemented earlier than this, needless to say.


If you made Makefile.in changes to get Gawk to build, here is how
you can navigate in the history. Firstly, stash those changes:

$ git stash --patch

Just say yes to your own changes; not to generated changes in awkgram.c and
such. Then throw away the build-induced changes:

$ git reset --hard

Then navigate to a given commit you want:

$ git checkout 5603143c58035b91f91ee31ab548b9b996156760 # or whatever

Then apply your stashed make-it-build changes (hopefully without conflicts):

$ git stash apply # applies the top stash without popping it away

[Kaz Kylheku]

On 2016-10-14, sean <se...@sean.eternal-september.org> wrote:
> Kaz Kylheku wrote:
>> I pointed to this: an answer I gave on StackOverflow (June 2016) to the
>> question
>>
>> "How to overcome “'aclocal-1.15' is missing on your system”
>> warning when compiling?"
>>
>> http://stackoverflow.com/questions/33278928/how-to-overcome-aclocal-1-15-is-missing-on-your-system-warning-when-compilin/37669184
>
>
> That's the post I've found a few times to get be past a few autotools
> problems myself.
>
> I get past the problems by running autoreconf -f -i

A user of Autoconf-ed software should not have auto-anything on their
machine!!! That's the whole damned original point: the the developer
uses a configuration language which generates a ./configure
script. This script is generated in ridiculously portable Bourne
shell code, so that it will run anywhere, and not depend on anything
other than a factory installation of the target environment with perhaps
a compiler added.

If the user has to run auto-anything to regenerate that script
before building the software, serious situational irony has occurred; a
cane emerges from behind the curtain, yanks the user off the stage by
the neck, and the audience bursts out in laughter.

[Andrew Schorr]

On Friday, October 14, 2016 at 3:56:41 PM UTC-4, Kenny McCormack wrote:
> Today, I did ./configure and it worked fine. Then I did "make" and it
> aborted almost immediately, with these error messages:

Please refer to the gawk docs for info on how to build from the git code:

https://www.gnu.org/software/gawk/manual/html_node/Derived-Files.html

The key is bootstrap.sh. Something like this should work:

./bootstrap.sh && ./configure && make

Regards,
Andy

[sean]

Kaz Kylheku wrote:
> A user of Autoconf-ed software should not have auto-anything on their
> machine!!! That's the whole damned original point: the the developer
> uses a configuration language which generates a ./configure
> script. This script is generated in ridiculously portable Bourne
> shell code, so that it will run anywhere, and not depend on anything
> other than a factory installation of the target environment with perhaps
> a compiler added.

Stepping outside of gawk for a moment...
https://github.com/Tarsnap/tarsnap/

check out the building from git section:
autoreconf -i
./configure
make

Does this means some form of autotools is necessary, or should
./configure do everything needed?

[Kaz Kylheku]

On 2016-10-14, sean <se...@sean.eternal-september.org> wrote:

./configure should do everything needed; the only time you should
ever have to use Autostuff is if you try to extend or alter
the configuration---i.e. you're developing the program, and you
need to detect additional things. Say you add networking support
and you want configure to detect some facts about the network API's.

The problem is that Autotools based projects get clever in their
Makefiles: they have make rules which look at the timestamps of
the Autotools-related files themselves and try to trigger rebuilds of
that material based on the timestamps.

"Oh look, your configure.ac has a newer timestamp than configure;
we must run autoconf to regenerate configure; and then of course
we must re-run configure; and only then we can build this program."

I suspect that the Autotools must themselves be adding these stupid
rules to the makefiles; nobody in their right mind would do this to
themselves or their downstream users.

There is no need for an incremental build to notice that configure
has to be rebuilt. Or if so, it can just print a warning.

Here would be a good way to handle it: have a "touch" target which
just updates the timestamps of the annoying files.

# Fantasy ... not actual:

$ make

Oops: your configure is out of date w.r.t configure.ac.
If configure really needs to be rebuilt type: "make reconfig".
You're gonna need Autotools installed for this!
If this is a false situation due to just timestamps, type "make touch"
to fix the timestamps, then "make".

$ make touch
touch configure # now newer than configure.ac
$ make
# No complaints ...


When you do run autotools to regenerate stuff, it is risky, because the
version might not match. You will notice that even though you haven't
touched configure.ac, for instance, when you run autoconf, it generates
a huge number of diffs in the configure script, because your autoconf
from the one the program's upstream maintainer used to produce the
shipping configure script. That introduces a risk! How do you know that
the wildly different configure script isn't doing something differently
which affects the program. Sure the program is the same foo-1.14.5,
on the same Frobozz Linux distribution that the author is using;
but the configure script is totally different; thus it is not exactly
the same program.

[Ian Zimmerman]

On 2016-10-14 22:35, Kaz Kylheku wrote:

> A user of Autoconf-ed software should not have auto-anything on their
> machine!!! That's the whole damned original point: the the developer
> uses a configuration language which generates a ./configure
> script. This script is generated in ridiculously portable Bourne
> shell code, so that it will run anywhere, and not depend on anything
> other than a factory installation of the target environment with perhaps
> a compiler added.

Right, but this kind of user was never expected to check out the source
from version control, only to download a release tarball and unpack it.

The problem is that the whole auto$ite model was conceived in the days
of RCS, and (I think) before free software distributions became
important. Both diffuse version control as in git or hg, and distros as
"users", break the model, but it nobody has ever rethought from scratch
as was appropriate.

--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html