automake
[Top][All Lists]
Advanced

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

Revert setting of CONFIG_COMMANDS when running config.status


From: Raja R Harinath
Subject: Revert setting of CONFIG_COMMANDS when running config.status
Date: 09 Feb 2001 13:08:21 -0600
User-agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/21.0.97

Hi,

Please revert the CONFIG_COMMANDS part of 

  2001-02-04  Kevin Ryde <address@hidden>

        * automake.in (handle_configure): Call config.status with empty
        CONFIG_LINKS and CONFIG_COMMANDS when regenerating a file.

This doesn't work with beta autoconf 2.49d and 

  AC_OUTPUT(outputs, commands)

syntax.  For example, 'automake's configure.in uses

  AC_OUTPUT([Makefile automake aclocal m4/Makefile tests/Makefile],
  [chmod +x automake aclocal])

However, 

  automake: $(top_builddir)/config.status automake.in
        cd $(top_builddir) && \
        CONFIG_FILES=$@ CONFIG_HEADERS= CONFIG_LINKS= CONFIG_COMMANDS= \
        $(SHELL) ./config.status

doesn't run the 'chmod +x automake'.  This is because the old
AC_OUTPUT syntax appears to be internally implemented via
CONFIG_COMMANDS, and the explicit setting interferes with that.  

This only affects beta autoconf, and CONFIG_COMMANDS was introduced
only with beta autoconf.  So, it is safe to revert this part.

I don't think similar changes should be incorporated in the future.
It would be better to migrate to the new config.status command line
interface if AC_PREREQ(2.50) is seen,

          ./config.status --files=$@

rather than depend on specific details of the implementation of
config.status.

I've attached a patch only to revert the CONFIG_COMMANDS case.  I
think the CONFIG_LINKS= part in the above is harmless.

- Hari

Attachment: automake.diff
Description: Revert CONFIG_COMMANDS patch

-- 
Raja R Harinath ------------------------------ address@hidden
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

reply via email to

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