Re: make -q and maintainer-makefile issues?

2011-08-19 Thread Ben Pfaff 
"Bruno Haible"  writes:

> Nevertheless, the gettext package tries to help you do that: It contains
> a file autogen.sh in the tarball, and it explains
>   "This script requires autoconf-2.60..2.65 and automake-1.11.1 in the PATH."

I would not have guessed that gettext was incompatible with
Autoconf versions later than 2.65.

Have you considered making gettext warn when its "configure" is
run with a too-new Autoconf?  Perhaps something like this:
  m4_version_prereq(
[2.66], 
[m4_warn([Only Autoconf 2.60..2.65 is supported.])],
[:])
-- 
Ben Pfaff 
http://benpfaff.org

Re: make -q and maintainer-makefile issues?

2011-08-18 Thread Charles Wilson 
On 8/18/2011 4:12 PM, Bruno Haible wrote:
> Charles Wilson writes:
>> On cygwin, we typically reautotool almost any package, as a routine part
>> of building it.
> 
> You are on your own when doing this. This is not the recommended
> way to build, explained in the INSTALL file.

Ack.

> Nevertheless, the gettext package tries to help you do that: It contains
> a file autogen.sh in the tarball,

Yes, that was what I was using to re-autotool (preceded by an explicit
libtoolize).

> and it explains
>   "This script requires autoconf-2.60..2.65 and automake-1.11.1 in the PATH."

That's the part I missed; I did look in configure for the autoconf
version you /did/ use to generate it, and ditto at Makefile.in for the
version of automake that was used.  The closest I had, ready to go, was
ac-2.64+am-1.11.1 -- the standard versions for current gcc development.
 And, as I said later in my original email, that appears to work...better.

> It is absolutely normal that, when you attempt to use newer autoconf or 
> automake
> versions than the ones listed, you have to do some legwork - either by 
> yourself
> or by picking the corresponding updates from the git repository of gettext.

I guess I'm mostly annoyed by my bad luck.  It seems that both when I
worked to create the cygwin-gettext-0.17 package, and lately with
cygwin-gettext-0.18.1.1, that the version of autoconf that cygwin was
using as the default installation, had each just implemented annoying
backwards-incompatible changes.  So, autoreconf'ing was more painful
that usual -- in BOTH cases.  Sucks to be me.

   gettext-0.17:
# Generated by GNU Autoconf 2.61.
but I was re-autoconf'ing with 2.63, which had the following
change, that didn't play nicely with contemporaneous gnulib
.m4 files
** AC_USE_SYSTEM_EXTENSIONS no longer conflicts with an external
   AC_DEFINE([__EXTENSIONS__]).  This fixes a regression introduced in
   2.62 when using macros such as AC_AIX that were made obsolete in
   favor of the more portable AC_USE_SYSTEM_EXTENSIONS.


   gettext-0.18.1.1
# Generated by GNU Autoconf 2.65.
but I originally attempted with 2.68, which introduced the
following extremely annoying behavior:
** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
   AC_RUN_IFELSE now warn if the first argument failed to use
   AC_LANG_SOURCE ...


However, since I had an /opt/foo/ installation of ac-2.64+am-1.11.1,
specifically for use with gcc, I used that -- and stuff worked...better.

> Or use a version of autoconf that is not newer than the release.

Ack. Or, if libtool-2.2.x is "new enough" for my purposes on cygwin,
suppress the re-autoconf step altogether. It's not like I'm patching
gettext's Makefile.am or configure.ac files -- this time (it has been
necessary in the evil dark past, circa 0.11.x or 0.12.x)

> Or pick the
> updates from the gettext git repository.

Folks tend to get annoyed when I use bleeding-edge for libraries as
fundamental as libintl...so that's probably a non-starter. :-)

>> it ignored my --with-libncurses-prefix and linked against the wrong 
>> libncurses...
> 
> This would be a bug, to be reported to bug-gettext, with enough details to
> let me reproduce it.

Hmmm...actually, I don't think it is a "bug", per se.  It's really just
revealing a shortcoming of ld.  ld adds -Lpaths to the search list /in
the order they appear/.  The writer of the Makefile (or Makefile.in or
Makefile.am) doesn't have any way of knowing that some libraries might
need to precede others -- not due to dependencies, but simply because
the END USER wants to force one lib to be picked from a custom dir, AND
that an unwanted version of the same lib appears in the directory that
the OTHER desired libs are located.

This is really one of those "Doctor, it hurts when I do this" moments:
Don't Do That.

>> I wanted the java stuff built as a .jar, not an .exe, so I did
>> --disable-native-java (but NOT --disable-java), but...no .jar.
> 
> The ability to build this jar depends on a Java compiler that has an
> option for selecting the output format (version of class file format).
> GCJ does not have this option; it's registered in the GCC bug tracker.
> The OpenJDK can be used instead in general; but I haven't tested
> that on Cygwin.

Oh. Well, there's no official cygwin-openjdk package; Yaakov at
cygwin-ports has not provided a version of it either.  It appears to
require the Microsoft DirectX 9.0 SDK; cygwin's (and mingw's) w32api
package does not provide complete support for directx...  I think this
is probably a non-starter.

It may be possible, from within cygwin, to use the following wrappers:
http://cygwin.com/cgi-bin/cvsweb.cgi/wrappers/java/?cvsroot=cygwin-apps
with the *windows* java SDK...but that kind of frankenbuild
(cygwin+native?) is more ambitious that I'm feeling at the moment.

>> libgettextlib doesn't actually
>> reference any of the DATA items exported by the libncurses DLL:
> 
> Correct.

Re: make -q and maintainer-makefile issues?

2011-08-18 Thread Bruno Haible 
[Un-CCing the coreutils list.]

Charles Wilson writes:
> Apparently it can be done -- provided you configure and build in a
> specific way.

Yes, gettext can be built as documented in the INSTALL file. Only one
extra option, --with-included-libxml, is needed on Cygwin.

> However, it does not appear to be buildable the way I
> *want* to build it.
> 
> On cygwin, we typically reautotool almost any package, as a routine part
> of building it.

You are on your own when doing this. This is not the recommended
way to build, explained in the INSTALL file.

Nevertheless, the gettext package tries to help you do that: It contains
a file autogen.sh in the tarball, and it explains
  "This script requires autoconf-2.60..2.65 and automake-1.11.1 in the PATH."

> configure.ac:71: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> /usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/lang.m4:194:
>  AC_LANG_CONFTEST is expanded from...

It is absolutely normal that, when you attempt to use newer autoconf or automake
versions than the ones listed, you have to do some legwork - either by yourself
or by picking the corresponding updates from the git repository of gettext.

> Now, concerning 0.18.1.1, I have run into this "warning:
> AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body" issue before,
> with other packages; I know how to fix it -- but it requires editing a
> bunch of m4 files.  It's a PITA.

Or use a version of autoconf that is not newer than the release. Or pick the
updates from the gettext git repository.

> it ignored my --with-libncurses-prefix and linked against the wrong 
> libncurses...

This would be a bug, to be reported to bug-gettext, with enough details to
let me reproduce it.

> I wanted the java stuff built as a .jar, not an .exe, so I did
> --disable-native-java (but NOT --disable-java), but...no .jar.

The ability to build this jar depends on a Java compiler that has an
option for selecting the output format (version of class file format).
GCJ does not have this option; it's registered in the GCC bug tracker.
The OpenJDK can be used instead in general; but I haven't tested
that on Cygwin.

> libgettextlib did link, successfully, against libncurses. I can
> only assume that, simply by luck, libgettextlib doesn't actually
> reference any of the DATA items exported by the libncurses DLL:
>   BC DATA
>   PC DATA
>   SP DATA
>   UP DATA
>   ospeed DATA
>   _nc_* stuff (these are internal symbols and probably
>  should not have been exported; call it
>  a upstream ncurses bug)

Correct.

> another rebuild cycle (which takes forEVER on cygwin)

I understand that long rebuild cycles are painful, but one can get used to it,
and develop techniques for managing long builds. My personal approach
is to create a checklist of commands to execute and check each of the steps
once it is done. And when I make experiments, I keep all log files for later
comparison, and write down every success or failure.

Bruno

Re: make -q and maintainer-makefile issues?

2011-08-18 Thread Charles Wilson 
On 8/12/2011 1:00 PM, Bruno Haible wrote:
> [CCing bug-gettext and Charles Wilson]
> Eric Blake wrote in [1]:
>> At least cygwin still ships with 
>> only gettext 0.17, because all versions of 0.18 are unbuildable on the 
>> current cygwin.
> 
> This is a myth, and is factually wrong.
...
>   * The Cygwin maintainer of gettext didn't put enough time into it.
>
> The other half of the diagnosis was incorrect:
> 
>   * No, gettext is not unbuildable on Cygwin.

Apparently it can be done -- provided you configure and build in a
specific way.  However, it does not appear to be buildable the way I
*want* to build it.

On cygwin, we typically reautotool almost any package, as a routine part
of building it.  This is mostly historical, but there are (still) good
reasons for it -- mainly having to do with the /patched/ versions of
libtool that we've commonly needed to use, and have provided by default,
on cygwin.

Also, cygport (the semi-de-facto-standard build tool for maintaining
cygwin packages) also typically forces updating gettext (in packages
other than gettext itself, naturally) to 0.17 at present, via autopoint
-V (our autopoint is hacked to re-enable the -V option).

Now, unlike earlier versions, stock libtool-2.2 was pretty good, for
native cygwin builds, so maybe we can skip updating libtool files now --
e.g. don't reautoconf or ./autogen at all.  (OTOH, cygport now supports
cross builds, and good support for cross builds to cygwin targets wasn't
added to libtool until 2.4...so if I wanted to build *and test* gettext
using linux->cygwin, with a WINE test env, I'd need to update libtool to
stock libtool 2.4, if not cygwin-libtool-2.4 which adds a few bugfixes)

The following ought to Just Work(tm):

.../gettext-0.18.1.1$ libtoolize --automake --copy --force
.../gettext-0.18.1.1$ ./autogen.sh --quick --skip-gnulib

but it doesn't:

configure.ac:71: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in b
ody
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/
lang.m4:194: AC_LANG_CONFTEST is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/
general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/
general.m4:2607: AC_COMPILE_IFELSE is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/m4sugar/m
4sh.m4:606: AS_IF is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/general.m4:2032:
AC_CACHE_VAL is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/general.m4:2053:
AC_CACHE_CHECK is expanded from...
gnulib-m4/include_next.m4:28: gl_INCLUDE_NEXT is expanded from...
gnulib-m4/include_next.m4:124: gl_CHECK_NEXT_HEADERS is expanded from...
gnulib-m4/gnulib-comp.m4:36: gl_INIT is expanded from...
configure.ac:71: the top level
configure.ac:71: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/lang.m4:194:
AC_LANG_CONFTEST is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/general.m4:2591:
_AC_COMPILE_IFELSE is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/general.m4:2607:
AC_COMPILE_IFELSE is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/m4sugar/m4sh.m4:606:
AS_IF is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/general.m4:2591:
_AC_COMPILE_IFELSE is expanded from...

etc etc etc

It's this sort of thing, every dadgum blasted time I try to build
gettext -- whatever the $DATE and $VERSION, that causes me to 'not put
enough time into it'.

For 0.17, it was the need to modify a bunch of the gnulib .m4 files:

-  AC_REQUIRE([AC_GNU_SOURCE])
-  AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
+  AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])

Not being an autoconf guru, that's what google told me to do, to fix
whatever error I originally ran into when re-bootstrapping gettext-0.17.

Now, concerning 0.18.1.1, I have run into this "warning:
AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body" issue before,
with other packages; I know how to fix it -- but it requires editing a
bunch of m4 files.  It's a PITA.



Since time is limited, I spend an hour or so...and give up for another
month or seven.  This is why cygwin-gettext is still 0.17.



On a wild hair, I just tried running autogen.sh with ac-2.64+am-1.11.1
first in my path, rather than ac-2.68+am-1.11.1 (don't ask why those
particular versions; it's what I had available) and that appeared to
work better...crossing fingers...seems to be MOSTLY ok...just a few
worrisome warnings in the build...and it ignored my
--with-libncurses-prefix and linked against the wrong libncurses...also,
I wanted the java stuff

Re: make -q and maintainer-makefile issues?

2011-08-14 Thread Paul Eggert 
On 08/14/2011 03:50 PM, Bruno Haible wrote:
> What is the difference between your test case
> 
> -
> all: foo
> foo: /etc/motd
>   cat /etc/motd >$@
> -
> 
> and the snippet from modules/relocatable-prog
> 
> ---
> uninstall-hook: uninstall-relocwrapper
> uninstall-relocwrapper:
>   some-statements;
> ---

My test case creates the file 'foo', but the snippet does not create a
file 'uninstall-relocwrapper'.

> and the pattern from po/Makefile.in.in:
> 
> -
> all : sanity
> all : foo
> sanity :
>   @test `expr 1 + 1` = 2
> foo :
>   echo > foo
> -

Similarly, my test case creates a file 'foo', but the 'sanity' rule
does not create a file 'sanity'.

>> If you can program a sanity check this way:
>>
>> sanity:
>>  @$(SANITY)
>>
>> where SANITY expands to the empty string if the check succeeds,
>> and to 'false' if it fails, then 'make -q' should work.  This is
>> true regardless of whether 'sanity' is phony.
> 
> An interesting idea. But in the special case of po/Makefile.in.in
> I cannot use it, without making use of GNU make $(...) function call
> expressions.

Can the sanity check be expressed as an Automake conditional?
That might do the trick.  (On the other hand, does gnulib
require Automake?)

Another possibility is to use a prefix +, like this:

all: sanity foo
sanity:
+@test `expr 1 + 1` = 2
foo:
touch $@

The '+' feature is something I wasn't aware of until just now.  It is
standardized by POSIX, but was not in Unix version 7.  I don't know
how portable it is in practice; I wouldn't recommend it unless we do
reasonably-extensive portability testing.  (It is not suitable for all
sanity checks; just for side-effect-free checks that do not depend on
anything other than other sanity checks.)

All in all, the approach taken in the gnulib now may be more
straightforward and portable than these alternatives.

Re: make -q and maintainer-makefile issues?

2011-08-14 Thread Bruno Haible 
Paul Eggert wrote:
> > I wouldn't want to kill all
> > phony targets from all Makefiles, just for "make -q".
> 
> Sorry, I see that I wasn't clear earlier.  Not all phony targets have
> the problem.  For example, the following works fine:
> 
> .PHONY: all
> 
> all: foo
> 
> foo: /etc/motd
>   cat /etc/motd >$@
> 
> The problem occurs only when a phony target has a nonempty action,
> and when "make -q" depends on the phony target.

Thanks for explaining. But I'm still not sure I understand. What is
the difference between your test case

-
all: foo
foo: /etc/motd
cat /etc/motd >$@
-

and the snippet from modules/relocatable-prog

---
uninstall-hook: uninstall-relocwrapper
uninstall-relocwrapper:
some-statements;
---

and the pattern from po/Makefile.in.in:

-
all : sanity
all : foo
sanity :
@test `expr 1 + 1` = 2
foo :
echo > foo
-

The target has non-empty statements in each case.

> If you can program a sanity check this way:
> 
> sanity:
>   @$(SANITY)
> 
> where SANITY expands to the empty string if the check succeeds,
> and to 'false' if it fails, then 'make -q' should work.  This is
> true regardless of whether 'sanity' is phony.

An interesting idea. But in the special case of po/Makefile.in.in
I cannot use it, without making use of GNU make $(...) function call
expressions.

Bruno
-- 
In memoriam Maximilian Kolbe

Re: make -q and maintainer-makefile issues?

2011-08-14 Thread Paul Eggert 
On 08/14/2011 03:19 AM, Bruno Haible wrote:
> I wouldn't want to kill all
> phony targets from all Makefiles, just for "make -q".

Sorry, I see that I wasn't clear earlier.  Not all phony targets have
the problem.  For example, the following works fine:

.PHONY: all

all: foo

foo: /etc/motd
cat /etc/motd >$@

The problem occurs only when a phony target has a nonempty action,
and when "make -q" depends on the phony target.

If you can program a sanity check this way:

sanity:
@$(SANITY)

where SANITY expands to the empty string if the check succeeds,
and to 'false' if it fails, then 'make -q' should work.  This is
true regardless of whether 'sanity' is phony.

Re: make -q and maintainer-makefile issues?

2011-08-14 Thread Bruno Haible 
Paul,

> What's the downside to the patch to build-aux/po/Makefile.in.in?
> If it's stylistic

Yes, it's only stylistic, but with major impact. I wouldn't want to kill all
phony targets from all Makefiles, just for "make -q". Let's hear what Paul
Smith can say about it...

Bruno
-- 
In memoriam Maximilian Kolbe

Re: make -q and maintainer-makefile issues?

2011-08-13 Thread Paul Eggert 
On 08/13/2011 04:06 PM, Bruno Haible wrote:
> I'm wondering whether we need to care about "make -q", or whether
> "make -q" is a hopeless case anyway.

"make -q" has been part of Make ever since The Beginning
(7th Edition Unix, anyway :-) and is standardized by POSIX.
I've used it in some of my metabuild procedures in the past,
and I'm not surprised to see others using it.  It'd be nice
to keep it working one way or another.

What's the downside to the patch to build-aux/po/Makefile.in.in?
If it's stylistic, perhaps the style could be changed without
breaking "make -q".

Re: make -q and maintainer-makefile issues?

2011-08-13 Thread Bruno Haible 
Hi Paul,

> > Does it mean phony targets are generally incompatible with "make -q"?
> 
> Apparently so

Thanks for the confirmation. I've raised the question on the bug-make list [1],
together with a pointer to your suggestion.

> In the meantime, though, we're stuck with workarounds such as the
> one I installed.

When, changes to po/Makefile.in.in ought to be added to gettext (upstream),
and I'm wondering whether we need to care about "make -q", or whether
"make -q" is a hopeless case anyway.

Bruno

[1] http://lists.gnu.org/archive/html/bug-make/2011-08/msg8.html (likely)
-- 
In memoriam Paul Richter

Re: make -q and maintainer-makefile issues?

2011-08-13 Thread Paul Eggert 
On 08/13/2011 11:10 AM, Bruno Haible wrote:
> Why is "make -q" looking for a file 'check-macro-version'
> although the target is declared phony?

I expect that it's because historically, 'make' always identified
rule names with file names, and .PHONY was introduced with
a minimum of change to the historical behavior.

I also tried using a double-colon rule for check-macro-version,
without .PHONY, and that didn't work with 'make -q' either.

> Does it mean phony targets are generally incompatible with "make -q"?

Apparently so, and that's what I would expect given the documentation
that you quoted: a phony target is always considered to be out-of-date,
so make -q FOO should fail if FOO is (or depends on) a phony target.

It might be worth extending GNU Make to add a new special target,
.CHECK say, which would attack this problem.  Any dependency of
.CHECK should be a rule that is executed purely for its exit status
and/or output to stdout or stderr, and all the dependencies of this
rule would have a similar restriction.  'make -q' could invoke
these rules' actions.  The rule names would not be associated with
file names.  (I haven't thought through this proposal carefully; I'm
throwing it out mostly to show the difference between .PHONY and
what's wanted here.)

In the meantime, though, we're stuck with workarounds such as the
one I installed.  In this particular case the workaround is not
so bad.

There may be similar problems elsewhere, in rules that create
time stamp files.  Getting such rules to work for both -j and -q
may be tricky.  I have not gone searching for problems
in that area, though.

Re: make -q and maintainer-makefile issues?

2011-08-13 Thread Bruno Haible 
Hi Paul,

> diff --git a/ChangeLog b/ChangeLog
> index d020dd5..3a798cf 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,5 +1,13 @@
>  2011-08-11  Paul Eggert  
>  
> + po/Makefile.in.in: fix make -q problem
> + * build-aux/po/Makefile.in.in (check-macro-version): Remove this
> + rule, since there's no file named 'check-macro-version' and its
> + use as a file breaks make -q.
> + (all): Don't depend on check-macro-version.
> + (CHECK_MACRO_VERSION): New macro.
> + (stamp-po): Use it.
> +
>   configmake: fix make -q problem
>   * modules/configmake (configmake.h): Update configmake.h's time stamp
>   even if the file does not change.  Otherwise, 'make -q' fails.
> diff --git a/build-aux/po/Makefile.in.in b/build-aux/po/Makefile.in.in
> index 83d8838..caedd7f 100644
> --- a/build-aux/po/Makefile.in.in
> +++ b/build-aux/po/Makefile.in.in
> @@ -96,14 +96,14 @@ CATALOGS = @CATALOGS@
>   mv t-$@ $@
>  
>  
> -all: check-macro-version all-@USE_NLS@
> +all: all-@USE_NLS@
>  
>  all-yes: stamp-po
>  all-no:
>  
>  # Ensure that the gettext macros and this Makefile.in.in are in sync.
> -check-macro-version:
> - @test "$(GETTEXT_MACRO_VERSION)" = "@GETTEXT_MACRO_VERSION@" \
> +CHECK_MACRO_VERSION = \
> + test "$(GETTEXT_MACRO_VERSION)" = "@GETTEXT_MACRO_VERSION@" \
> || { echo "*** error: gettext infrastructure mismatch: using a 
> Makefile.in.in from gettext version $(GETTEXT_MACRO_VERSION) but the autoconf 
> macros are from gettext version @GETTEXT_MACRO_VERSION@" 1>&2; \
>  exit 1; \
>}
> @@ -123,6 +123,7 @@ check-macro-version:
>  # $(POFILES) has been designed to not touch files that don't need to be
>  # changed.
>  stamp-po: $(srcdir)/$(DOMAIN).pot
> + @$(CHECK_MACRO_VERSION)
>   test ! -f $(srcdir)/$(DOMAIN).pot || \
> test -z "$(GMOFILES)" || $(MAKE) $(GMOFILES)
>   @test ! -f $(srcdir)/$(DOMAIN).pot || { \

Why can't this be done by adding the line

.PHONY: check-macro-version

? I just tried it, "make -q -d" outputs

...
Considering target file `all'.
 File `all' does not exist.
 Looking for an implicit rule for `all'.
 ...
 No implicit rule found for `all'.
  Considering target file `check-macro-version'.
   File `check-macro-version' does not exist.
   Finished prerequisites of target file `check-macro-version'.
  Must remake target `check-macro-version'.
  Target file `check-macro-version' needs remade under -q.
 Finished prerequisites of target file `all'.
Giving up on target file `all'.

and terminates with exit code 1.

Why is that? Why is "make -q" looking for a file 'check-macro-version'
although the target is declared phony?

Does it mean phony targets are generally incompatible with "make -q"?

I'm referring to the GNU make documentation, which says:

  `.PHONY'
 The prerequisites of the special target `.PHONY' are considered to
 be phony targets.  When it is time to consider such a target,
 `make' will run its commands unconditionally, regardless of
 whether a file with that name exists or what its last-modification
 time is.

and I'm using GNU make 3.81. GNU make 3.82 behaves the same way.

Bruno
-- 
In memoriam Paul Richter

Re: make -q and maintainer-makefile issues?

2011-08-12 Thread Bruno Haible 
[CCing bug-gettext and Charles Wilson]
Eric Blake wrote in [1]:
> At least cygwin still ships with 
> only gettext 0.17, because all versions of 0.18 are unbuildable on the 
> current cygwin.

This is a myth, and is factually wrong.

I just built gettext 0.18.1.1 on a Cygwin 1.7.5 system, with gcc 4.3.4,
and it passed "make check" with only 1 failure in lang-tcl, and
"make install" succeeded as well. Likewise on Cygwin 1.7.9, with
gcc 4.3.4 as well. The build command was:

$ mkdir build3
$ cd build3
$ ../configure --prefix=/usr/local/cygwin \
   CPPFLAGS="-I/usr/local/cygwin/include -Wall" \
   LDFLAGS="-L/usr/local/cygwin/lib" \
   --with-included-libxml 2>&1 | tee log1
$ make 2>&1 | tee log2
$ make check 2>&1 | tee log3
$ make install 2>&1 | tee log4

Reviewing the history of these build reports:

* Eric Blake tried to build it on 2010-06-16 [2], got the error

  undefined reference to `_xmlFree'

  I recommended trying --without-libxml2-prefix [3]. This would have helped
  if libxml2 was installed in a nonstandard location. But it's installed in
  /usr/lib/, so the option that's needed is --with-included-libxml.

  He reports that he "ran into a bug with the cygwin linker claiming that
  libintl.dll.a had an invalid symbol relocation". Well, on Cygwin 1.7.5
  and 1.7.9 I don't run into this bug. So, install Cygwin 1.7.5 or 1.7.9,
  and you can build gettext binaries.

* Markus Moeller reported this error [4]

   collect2: ld terminated with signal 6 [Aborted]
   /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: 
/usr/lib/libintl.dll.a(d50.o): illegal symbol index 1633970 478 in relocs
   make[4]: *** [msgcmp.exe] Error 1

  whereupon Corinna Vinschen put the blame on gettext [5].
  Then Markus Moeller gave it a try with the opposite flag than what
  what gettext uses and found that the same linker error still existed [6].
  So it was *not* a problem with gettext's use of --disable-auto-import.

* After which Eric Blake continued to report that gettext 0.18 does not
  build on Cygwin 1.7. [7]

Half of his diagnosis in [7] was correct:

  * The xmlFree link error is a consequence of --disable-auto-import.
Witness:

$ cat > foo.c <
#include 
int main ()
{
  xmlCheckVersion (0); xmlFree ((void *) 0);
  return 0;
}
EOF
$ gcc -I/usr/include/libxml2 foo.c -lxml2
[works fine]
$ gcc -I/usr/include/libxml2 foo.c -lxml2 -Wl,--disable-auto-import
/tmp/cc4EveXj.o:foo.c:(.text+0x23): undefined reference to `_xmlFree'
collect2: ld returned 1 exit status

But gettext's configure provides the right option to fix it. You
only need to do "./configure --help | grep xml".

Additionally, the next version of gettext will detect this situation
automatically.

  * The Cygwin maintainer of gettext didn't put enough time into it.

The other half of the diagnosis was incorrect:

  * No, gettext is not unbuildable on Cygwin.

  * No, the collect2 linker crash has been demonstrated to also occur
with --enable-auto-import.

I hope, with this mail, I've helped to separate truth from myth.

Please, next time, be more modest and don't say "gettext is unbuildable",
but rather "I have not succeeded in building gettext".

Bruno

[1] http://lists.gnu.org/archive/html/bug-gnulib/2011-08/msg00099.html
[2] http://lists.gnu.org/archive/html/bug-gnu-utils/2010-06/msg00057.html
[3] http://lists.gnu.org/archive/html/bug-gnu-utils/2010-06/msg00061.html
[4] http://cygwin.com/ml/cygwin/2010-08/msg00082.html
[5] http://cygwin.com/ml/cygwin/2010-08/msg00154.html
[6] http://cygwin.com/ml/cygwin/2010-08/msg00157.html
[7] http://www.cygwin.com/ml/cygwin/2011-01/msg00400.html
[8] 
http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=fcf0f235f4dd3e6ceb2149002834223b1c7e9f47
-- 
In memoriam Itzik Feffer

Re: make -q and maintainer-makefile issues?

2011-08-11 Thread Paul Eggert 
On 08/11/2011 06:49 PM, Eric Blake wrote:
> I'm not sure if we should revert this part of your change.

Unfortunately if that part is reverted, then coreutils would lose
all gnulib fixes in the gettext area, due to the funny way that
'bootstrap' invokes autopoint.  This includes not only the fix for
make -q but also fixes for uClibc, ksh's FPATH, visibility decls, and
probably some other stuff (I got tired of reading the diff).

If there's some way to keep the gnulib gettext fixes, but still
bootstrap on Cygwin, that'd be good.  In the meantime, surely it's
not a great loss if coreutils can't bootstrap on Cygwin.
Bootstrapping is for developers who have recent tools, and we
needn't worry overly much about bootstrapping on platforms that
don't have up-to-date tools.

Re: make -q and maintainer-makefile issues?

2011-08-11 Thread Eric Blake 

On 08/11/2011 07:45 PM, Paul Eggert wrote:

On 08/11/2011 11:28 AM, Paul Eggert wrote:

I'll look at coreutils shortly.


... and I discovered that coreutils was still using gettext 0.17 (!)


To some degree, that was intentional.  At least cygwin still ships with 
only gettext 0.17, because all versions of 0.18 are unbuildable on the 
current cygwin.


Pushing this change makes it impossible to do a bootstrap of coreutils 
on cygwin.  :(



* bootstrap.conf (gnulib_modules): Use gettext, not gettext-h.


'gettext' is used when you want bleeding edge, and requires 0.18.1. 
'gettext-h' is when you don't care about bleeding edge, and instead want 
to be portable to distros that are still at 0.17 (this includes popular 
distros like RHEL 5 and CentOS 5).  I'm not sure if we should revert 
this part of your change.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: make -q and maintainer-makefile issues?

2011-08-11 Thread Paul Eggert 
On 08/11/2011 11:28 AM, Paul Eggert wrote:
> I'll look at coreutils shortly.

... and I discovered that coreutils was still using gettext 0.17 (!)
via autopoint, so it didn't pick up the gnulib patch (and it was missing
several other gnulib fixes since 0.17).  I installed the
following into coreutils to fix the problem.  In testing builds I found
some other porting issues, in gnulib getaddrinfo and in coreutils
pathchk, and will try to follow up on them soon.

>From 99399c6c8a6d65b359493d8bf9a9572dd98d200f Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 11 Aug 2011 11:42:03 -0700
Subject: [PATCH] bootstrap: use latest gnulib bootstrap, gettext

* bootstrap: Sync from gnulib.  This removes an obsolescent
gettext.m4 patch, along with some other changes that do not
seem to affect coreutils.
* bootstrap.conf (gnulib_modules): Use gettext, not gettext-h.
Current gnulib gettext seems to work without needing special hacking.
* configure.ac (AM_GNU_GETTEXT_VERSION): Now 0.18.1, not 0.17.
* gnulib: Update to latest.
---
 bootstrap  |  100 ++--
 bootstrap.conf |2 +-
 configure.ac   |2 +-
 gnulib |2 +-
 4 files changed, 64 insertions(+), 42 deletions(-)

diff --git a/bootstrap b/bootstrap
index c45ae48..f76db9a 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Print a version string.
-scriptversion=2011-05-03.08; # UTC
+scriptversion=2011-08-11.17; # UTC
 
 # Bootstrap this package from checked-out sources.
 
@@ -130,18 +130,7 @@ source_base=lib
 m4_base=m4
 doc_base=doc
 tests_base=tests
-
-# Extra files from gnulib, which override files from other sources.
-gnulib_extra_files="
-$build_aux/install-sh
-$build_aux/missing
-$build_aux/mdate-sh
-$build_aux/texinfo.tex
-$build_aux/depcomp
-$build_aux/config.guess
-$build_aux/config.sub
-doc/INSTALL
-"
+gnulib_extra_files=''
 
 # Additional gnulib-tool options to use.  Use "\newline" to break lines.
 gnulib_tool_option_extras=
@@ -229,6 +218,18 @@ case "$0" in
   *) test -r "$0.conf" && . ./"$0.conf" ;;
 esac
 
+# Extra files from gnulib, which override files from other sources.
+test -z "${gnulib_extra_files}" && \
+  gnulib_extra_files="
+$build_aux/install-sh
+$build_aux/missing
+$build_aux/mdate-sh
+$build_aux/texinfo.tex
+$build_aux/depcomp
+$build_aux/config.guess
+$build_aux/config.sub
+doc/INSTALL
+"
 
 if test "$vc_ignore" = auto; then
   vc_ignore=
@@ -278,14 +279,29 @@ if test -n "$checkout_only_file" && test ! -r 
"$checkout_only_file"; then
   exit 1
 fi
 
+# Ensure that lines starting with ! sort last, per gitignore conventions
+# for whitelisting exceptions after a more generic blacklist pattern.
+sort_patterns() {
+  sort -u "$@" | sed '/^!/ {
+H
+d
+  }
+  $ {
+P
+x
+s/^\n//
+  }' | sed '/^$/d'
+}
+
 # If $STR is not already on a line by itself in $FILE, insert it,
 # sorting the new contents of the file and replacing $FILE with the result.
 insert_sorted_if_absent() {
   file=$1
   str=$2
   test -f $file || touch $file
-  echo "$str" | sort -u - $file | cmp - $file > /dev/null \
-|| echo "$str" | sort -u - $file -o $file \
+  echo "$str" | sort_patterns - $file | cmp - $file > /dev/null \
+|| { echo "$str" | sort_patterns - $file > $file.bak \
+  && mv $file.bak $file; } \
 || exit 1
 }
 
@@ -409,17 +425,28 @@ check_versions() {
 GZIP) ;; # Do not use $GZIP:  it contains gzip options.
 *) eval "app=\${$appvar-$app}" ;;
 esac
-inst_ver=$(get_version $app)
-if [ ! "$inst_ver" ]; then
-  echo "$me: Error: '$app' not found" >&2
-  ret=1
-elif [ ! "$req_ver" = "-" ]; then
-  latest_ver=$(sort_ver $req_ver $inst_ver | cut -d' ' -f2)
-  if [ ! "$latest_ver" = "$inst_ver" ]; then
-echo "$me: Error: '$app' version == $inst_ver is too old" >&2
-echo "   '$app' version >= $req_ver is required" >&2
+if [ "$req_ver" = "-" ]; then
+  # Merely require app to exist; not all prereq apps are well-behaved
+  # so we have to rely on $? rather than get_version.
+  $app --version >/dev/null 2>&1
+  if [ 126 -le $? ]; then
+echo "$me: Error: '$app' not found" >&2
 ret=1
   fi
+else
+  # Require app to produce a new enough version string.
+  inst_ver=$(get_version $app)
+  if [ ! "$inst_ver" ]; then
+echo "$me: Error: '$app' not found" >&2
+ret=1
+  else
+latest_ver=$(sort_ver $req_ver $inst_ver | cut -d' ' -f2)
+if [ ! "$latest_ver" = "$inst_ver" ]; then
+  echo "$me: Error: '$app' version == $inst_ver is too old" >&2
+  echo "   '$app' version >= $req_ver is required" >&2
+  ret=1
+fi
+  fi
 fi
   done
 
@@ -643,10 +670,18 @@ symlink_to_dir()
 cp -fp "$src" "$dst"
   }
 else
+  # Leave any ex

Re: make -q and maintainer-makefile issues?

2011-08-11 Thread Paul Eggert 
On 08/11/2011 11:46 AM, Eric Blake wrote:
> I think we need a better solution that involves a stamp file

Yes, that could also be done, and please feel free to do that.

I've been moving away from stamp files like that lately, though,
as these days they seem to be more trouble than they're worth,
at least for me.  If you do create a stamp file, please make
sure that it works with parallel makes.  A common problem
is that there must be an unstated dependency between the
configmake.h stamp file, and the file FOO that depends
on configmake.h.  (This dependency must be unstated, as that's
the whole point of the stamp file.)  The unstated dependency often
messes up the parallel make.  The problem can be worked around,
though I don't remember offhand how to do that, and the complexity
of doing it "right" has led me to think that it shouldn't be done
at all.

Re: make -q and maintainer-makefile issues?

2011-08-11 Thread Eric Blake 

On 08/11/2011 12:28 PM, Paul Eggert wrote:


* modules/configmake (configmake.h): Update configmake.h's time stamp
even if the file does not change.  Otherwise, 'make -q' fails.
Problem reported by Simon Josefsson in
.


Ouch.  This goes against the idea that configmake.h should not change 
timestamps if it does not change contents, since it can result in a lot 
of needless recompilations.  I think we need a better solution that 
involves a stamp file; where C programs that depend on the definitions 
depend on configmake.h, but make rules that ensure configmake.h is 
correct instead depend on the stamp file rather than configmake.h, and 
where the stamp file always has an up-to-date timestamp any time the 
rules get rerun even if configmake.h does not change.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: make -q and maintainer-makefile issues?

2011-08-11 Thread Paul Eggert 
On 08/10/2011 02:36 PM, Simon Josefsson wrote:
> A user reported that 'make -q' didn't work:
> 
> http://permalink.gmane.org/gmane.comp.gnu.libidn.general/329
> 
> and I cannot seem to debug this properly.

I used "make -d" with coreutils, and found a couple of problems in
both gnulib and coreutils.  I pushed the following into gnulib
to fix its problems with "make -q".  I'll look at coreutils shortly.

>From 234576dda786bb799607483df76df34023263721 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 11 Aug 2011 11:20:28 -0700
Subject: [PATCH 1/2] configmake: fix make -q problem

* modules/configmake (configmake.h): Update configmake.h's time stamp
even if the file does not change.  Otherwise, 'make -q' fails.
Problem reported by Simon Josefsson in
.
---
 ChangeLog  |8 
 modules/configmake |8 ++--
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f6e27cd..d020dd5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2011-08-11  Paul Eggert  
+
+   configmake: fix make -q problem
+   * modules/configmake (configmake.h): Update configmake.h's time stamp
+   even if the file does not change.  Otherwise, 'make -q' fails.
+   Problem reported by Simon Josefsson in
+   .
+
 2011-08-11  Jim Meyering  
 
git-version-gen: correct the advice in a comment
diff --git a/modules/configmake b/modules/configmake
index a387984..46c0fcc 100644
--- a/modules/configmake
+++ b/modules/configmake
@@ -44,12 +44,8 @@ configmake.h: Makefile
  echo '#define PKGINCLUDEDIR "$(pkgincludedir)"'; \
  echo '#define PKGLIBDIR "$(pkglibdir)"'; \
  echo '#define PKGLIBEXECDIR "$(pkglibexecdir)"'; \
-   } | sed '/""/d' > $@-t && \
-   if test -f $@ && cmp $@-t $@ > /dev/null; then \
- rm -f $@-t; \
-   else \
- rm -f $@; mv $@-t $@; \
-   fi
+   } | sed '/""/d' > $@-t
+   mv -f $@-t $@
 
 BUILT_SOURCES += configmake.h
 CLEANFILES += configmake.h configmake.h-t
-- 
1.7.4.4


>From 94c0bb57110d59a21a6c6e2ea4f48973a5fbc3e1 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 11 Aug 2011 10:46:26 -0700
Subject: [PATCH 2/2] po/Makefile.in.in: fix make -q problem

* build-aux/po/Makefile.in.in (check-macro-version): Remove this
rule, since there's no file named 'check-macro-version' and its
use as a file breaks make -q.
(all): Don't depend on check-macro-version.
(CHECK_MACRO_VERSION): New macro.
(stamp-po): Use it.
---
 ChangeLog   |8 
 build-aux/po/Makefile.in.in |7 ---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d020dd5..3a798cf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
 2011-08-11  Paul Eggert  
 
+   po/Makefile.in.in: fix make -q problem
+   * build-aux/po/Makefile.in.in (check-macro-version): Remove this
+   rule, since there's no file named 'check-macro-version' and its
+   use as a file breaks make -q.
+   (all): Don't depend on check-macro-version.
+   (CHECK_MACRO_VERSION): New macro.
+   (stamp-po): Use it.
+
configmake: fix make -q problem
* modules/configmake (configmake.h): Update configmake.h's time stamp
even if the file does not change.  Otherwise, 'make -q' fails.
diff --git a/build-aux/po/Makefile.in.in b/build-aux/po/Makefile.in.in
index 83d8838..caedd7f 100644
--- a/build-aux/po/Makefile.in.in
+++ b/build-aux/po/Makefile.in.in
@@ -96,14 +96,14 @@ CATALOGS = @CATALOGS@
mv t-$@ $@
 
 
-all: check-macro-version all-@USE_NLS@
+all: all-@USE_NLS@
 
 all-yes: stamp-po
 all-no:
 
 # Ensure that the gettext macros and this Makefile.in.in are in sync.
-check-macro-version:
-   @test "$(GETTEXT_MACRO_VERSION)" = "@GETTEXT_MACRO_VERSION@" \
+CHECK_MACRO_VERSION = \
+   test "$(GETTEXT_MACRO_VERSION)" = "@GETTEXT_MACRO_VERSION@" \
  || { echo "*** error: gettext infrastructure mismatch: using a 
Makefile.in.in from gettext version $(GETTEXT_MACRO_VERSION) but the autoconf 
macros are from gettext version @GETTEXT_MACRO_VERSION@" 1>&2; \
   exit 1; \
 }
@@ -123,6 +123,7 @@ check-macro-version:
 # $(POFILES) has been designed to not touch files that don't need to be
 # changed.
 stamp-po: $(srcdir)/$(DOMAIN).pot
+   @$(CHECK_MACRO_VERSION)
test ! -f $(srcdir)/$(DOMAIN).pot || \
  test -z "$(GMOFILES)" || $(MAKE) $(GMOFILES)
@test ! -f $(srcdir)/$(DOMAIN).pot || { \
-- 
1.7.4.4