bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Still the version.texi feature of Automake


From: Herbert Euler
Subject: Still the version.texi feature of Automake
Date: Thu, 12 Jun 2008 10:27:52 +0800

Hi,

I encountered a problem with Makefile generated with the help of GNU
Automake and GNU Make.  It has been reported to Make's mailing list,
but according to

  http://lists.gnu.org/archive/html/bug-make/2008-06/msg00028.html

the problem is with GNU Automake.

The problem is also reported to Automake's mailing list here:

  http://lists.gnu.org/archive/html/automake/2008-06/msg00054.html

but there's no reply until now.  For the sake of concision, this post
only contains a short description of the problem, please see the above
links for details.

The problem is that, with some texinfo file including `version.texi',
the info format document isn't updated in a single execution of `make'
in the top level directory when the project's version has been
updated.  According to the dependencies in Makefile.in, this is not
expected.

The two rules involved in the problem, and their actions, are listed
below:

  ## Don't give this rule a command (even `@:').
  ## %STAMPVTI% is always newer than %VTEXI%, so this rule is always
  ## triggered.  If you equip this rule with a command, GNU make will
  ## assume %VTEXI% has been rebuild in the current directory and
  ## discard any %VTEXI% file found in a VPATH search.
  %VTEXI%: %MAINTAINER-MODE% %STAMPVTI%

  ## Depend on configure so that version number updates cause a rebuild.
  ## (Not configure.ac, because not all setups define the version number
  ## in this file.)
  %STAMPVTI%: %TEXI% $(top_srcdir)/configure
  ## It is wrong to have %STAMPVTI% dependent on %DIRSTAMP%, because
  ## %STAMPVTI% is distributed and %DIRSTAMP% isn't: a distributed file
  ## should never be dependent upon a non-distributed built file.
  ## Therefore we ensure that %DIRSTAMP% exists in the rule.
  ?DIRSTAMP?        test -f %DIRSTAMP% || $(MAKE) $(AM_MAKEFLAGS) %DIRSTAMP%
          @(dir=.; test -f ./%TEXI% || dir=$(srcdir); \
          set `$(SHELL) %MDDIR%mdate-sh $$dir/%TEXI%`; \
          echo "@set UPDATED $$1 $$2 $$3"; \
          echo "@set UPDATED-MONTH $$2 $$3"; \
          echo "@set EDITION $(VERSION)"; \
          echo "@set VERSION $(VERSION)")> %VTI%.tmp
  ## Use cp and rm here because some older "mv"s can't move across
  ## filesystems.  Furthermore, GNU "mv" in the AmigaDOS environment
  ## can't handle this.
          @cmp -s %VTI%.tmp %VTEXI% \
            || (echo "Updating %VTEXI%"; \
                cp %VTI%.tmp %VTEXI%)
          address@hidden -f %VTI%.tmp
          @cp %VTEXI% $@

In these rules, `%VTEXI%' gets updated in `%STAMPVTI%''s commands,
which can't get (at least) GNU Make's attention, so at the first time
`make' is executed the info format file will not get rebuilt.

I wanted to move the commands updating `%VTEXI%' into `%VTEXI%''s
rule, but the comment before its rule prevented me doing that.  It
seems the empty action of `%VTEXI%' is intended, although this leads
to an undesired behavior.

Without an understanding to the bigger picture, I can't figure out
what is the right thing to do here.  Could somebody fix it, to correct
the current unexpected behavior of Automake generated Makefile?
Thanks.

Regards,
Guanpeng Xu

PS: Please reply this even if it is not a bug.  If it is intended to
execute `make' twice to rebuild the info format document when version
number is updated, I think it should be at least documented in
Automake's info, as most people would presume only once.
_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE




reply via email to

[Prev in Thread] Current Thread [Next in Thread]