Re: manual: Why use 'maude' as the example program name?

[Tom Tromey]

> "Bob" == Bob Friesenhahn  writes:

Bob> I think that we should have respect for the author's
Bob> dog. Disrespecting the author's dog is not far from disrespecting the
Bob> author.

Haha, well my memory of my dog is why I'd rather keep the text.  It's
fine to disrespect me, but not Maude -- she was great & hilarious :-)

Tom

bug#30612: [automake-1.16] make check fails on Solaris 11.3 x86

[Kiyoshi KANAZAWA]

Hello,

Trying to install automake-1.16 on Solaris 11.3 x86.
make check fails with

FAIL: t/lex-clean-cxx.sh
FAIL: t/lex-depend-cxx.sh


It seems to be caused by declaration of yylex ().
lex-clean-cxx.log & lex-depend-cxx.log are attached.


Tested with gcc 7.3.0, 

% ./configure
% make
% make check


Regards,

--- Kiyoshi


logs.tar.xz
Description: Binary data

Re: manual: Why use 'maude' as the example program name?

[Bob Friesenhahn]

I think that we should have respect for the author's dog. 
Disrespecting the author's dog is not far from disrespecting the 
author.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: manual: Why use 'maude' as the example program name?

[Mathieu Lirzin]

Tom Tromey  writes:

>> "Jonas" == Jonas Thiem  writes:
>
> Jonas> Disclaimer: I haven't read this part of the docs myself. But for what
> Jonas> it's worth, I think Maude looks a bit like a misspelling of Make and
> Jonas> doesn't stick out that well, compared to "exampleprog" or something.
>
> One such section starts:
>
>In the list below, we use the name “maude” to refer to the program or
> library.  In your ‘Makefile.am’ you would replace this with the
> canonical name of your program.  This list also refers to “maude” as a
> program, but in general the same rules apply for both static and dynamic
> libraries; the documentation below notes situations where programs and
> libraries differ.
>

FWIW, I think using “maude” with the above explanation is clear enough.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: manual: Why use 'maude' as the example program name?

[Tom Tromey]

> "Jonas" == Jonas Thiem  writes:

Jonas> Disclaimer: I haven't read this part of the docs myself. But for what
Jonas> it's worth, I think Maude looks a bit like a misspelling of Make and
Jonas> doesn't stick out that well, compared to "exampleprog" or something.

One such section starts:

   In the list below, we use the name “maude” to refer to the program or
library.  In your ‘Makefile.am’ you would replace this with the
canonical name of your program.  This list also refers to “maude” as a
program, but in general the same rules apply for both static and dynamic
libraries; the documentation below notes situations where programs and
libraries differ.

I guess my view is that in all the years of Automake, if we're first
hearing about it now, then it probably isn't really that confusing.
Also AFAICT it isn't mentioned on stack overflow.

Tom

GNU Automake 1.16 released

[Mathieu Lirzin]

We are pleased to announce the GNU Automake 1.16 minor release.

This release follows 1.15.1 which was made 8 months ago.

See below for the detailed list of changes since the
previous version, as summarized by the NEWS file.

Download here:

  https://ftp.gnu.org/gnu/automake/automake-1.16.tar.gz
  https://ftp.gnu.org/gnu/automake/automake-1.16.tar.xz

Please report bugs and problems to ,
and send general comments and feedback to .

Thanks to everyone who has reported problems, contributed
patches, and helped testing Automake!

-*-*-*-

* WARNING: Future backward-incompatibilities!

  - Makefile recipes generated by Automake 2.0 will expect to use an
'rm' program that doesn't complain when called without any non-option
argument if the '-f' option is given (so that commands like "rm -f"
and "rm -rf" will act as a no-op, instead of raising usage errors).
This behavior of 'rm' is very widespread in the wild, and it will be
required in the next POSIX version:

  

Accordingly, AM_INIT_AUTOMAKE now expands some shell code that checks
that the default 'rm' program in PATH satisfies this requirement,
aborting the configure process if this is not the case.  For the
moment, it's still possible to force the configuration process to
succeed even with a broken 'rm', that that will no longer be the case
for Automake 2.0.

  - Automake 2.0 will require Autoconf 2.70 or later (which is still
unreleased at the moment of writing, but is planned to be released
before Automake 2.0 is).

  - Automake 2.0 will drop support for the long-deprecated 'configure.in'
name for the Autoconf input file.  You are advised to start using the
recommended name 'configure.ac' instead, ASAP.

  - The ACLOCAL_AMFLAGS special make variable will be fully deprecated in
Automake 2.0: it will raise warnings in the "obsolete" category (but
still no hard error of course, for compatibilities with the many, many
packages that still relies on that variable).  You are advised to
start relying on the new Automake support for AC_CONFIG_MACRO_DIRS
instead (which was introduced in Automake 1.13).

  - Automake 2.0 will remove support for automatic dependency tracking
with the SGI C/C++ compilers on IRIX.  The SGI depmode has been
reported broken "in the wild" already, and we don't think investing
time in debugging and fixing is worthwhile, especially considering
that SGI has last updated those compilers in 2006, and retired
support for them in December 2013:


  - Automake 2.0 will remove support for MS-DOS and Windows 95/98/ME
(support for them was offered by relying on the DJGPP project).
Note however that both Cygwin and MSYS/MinGW on modern Windows
versions will continue to be fully supported.

  - Automake-provided scripts and makefile recipes might (finally!)
start assuming a POSIX shell in Automake 2.0.  There still is no
certainty about this though: we'd first like to wait and see
whether future Autoconf versions will be enhanced to guarantee
that such a shell is always found and provided by the checks in
./configure.

  - Starting from Automake 2.0, third-party m4 files located in the
system-wide aclocal directory, as well as in any directory listed
in the ACLOCAL_PATH environment variable, will take precedence
over "built-in" Automake macros.  For example (assuming Automake
is installed in the /usr/local hierarchy), a definition of the
AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
should take precedence over the same-named automake-provided macro
(defined in '/usr/local/share/aclocal-2.0/vala.m4').



New in 1.16:

* Miscellaneous changes

  - When subdir-objects is in effect, Automake will now construct
shorter object file names when no programs and libraries name
clashes are encountered.  This should make the discouraged use of
'foo_SHORTNAME' unnecessary in many cases.

* Bugs fixed:

  - Automatic dependency tracking has been fixed to work also when the
'subdir-object' option is used and some 'foo_SOURCES' definition
contains unexpanded references to make variables, as in, e.g.:

a_src = sources/libs/aaa
b_src = sources/bbb
foo_SOURCES = $(a_src)/bar.c $(b_src)/baz.c

With such a setup, the created makefile fragment containing dependency
tracking information will be correctly placed under the directories
named 'sources/libs/aaa/.deps' and 'sources/bbb/.deps', rather than
mistakenly under directories named (literally!) '$(src_a)/.deps' and
'$(src_b)/.deps' (this was the first part of automake bug#13928).

Notice that in order to fix this bug we had to slightly change the

Re: manual: Why use 'maude' as the example program name?

[Jonas Thiem]

On 02/25/2018 06:20 PM, Tom Tromey wrote:
>> "Kang-Che" == Kang-Che Sung  writes:
> 
> Kang-Che> And I really wonder one thing: Why these obscure name had been
> Kang-Che> chosen, instead of having a name like "myprog", "foo" or
> Kang-Che> "fooprog" that is more obvious as a placeholder?
> 
> It's easily distinguished from any ordinary text and I have a dislike of
> "foo" as an example.  Also Maude was the name of my dog.

Disclaimer: I haven't read this part of the docs myself. But for what
it's worth, I think Maude looks a bit like a misspelling of Make and
doesn't stick out that well, compared to "exampleprog" or something.
Also, I personally would suggest it's good if it's obvious from the name
what it is, and what it's not. (e.g. Maude could be mistaken as a
reference to an actual tool or some technical term the reader might
think they have missed) Not saying it needs to be changed, just throwing
in another impression.

Regards,
Jonas Thiem

Re: manual: Why use 'maude' as the example program name?

[Tom Tromey]

> "Kang-Che" == Kang-Che Sung  writes:

Kang-Che> And I really wonder one thing: Why these obscure name had been
Kang-Che> chosen, instead of having a name like "myprog", "foo" or
Kang-Che> "fooprog" that is more obvious as a placeholder?

It's easily distinguished from any ordinary text and I have a dislike of
"foo" as an example.  Also Maude was the name of my dog.

Kang-Che> This had troubled me when I need to look up the meanings of
Kang-Che> Automake variables frequently in order to write a debug an
Kang-Che> Automake file. And I hope the keywords can be indexed in a
Kang-Che> better way.

IMO the index should refer to definitions of primaries but not the names
used in examples.

Tom

manual: Why use 'maude' as the example program name?

[Kang-Che Sung]

In Automake manual, I see several places where it uses "maude" or "mumble"
as
 example name of program, even in the Indices section. And I really wonder
one
thing: Why these obscure name had been chosen, instead of having a name like
"myprog", "foo" or "fooprog" that is more obvious as a placeholder?

This had troubled me when I need to look up the meanings of Automake
variables
frequently in order to write a debug an Automake file. And I hope the
keywords can be indexed in a better way.