Bug#341263: autoconf doesn't realise its cache is out of date when included files change

2005-12-13 Thread pmaydell
Ben Pfaff wrote:
There are at least two different issues here.  The first is
simply that Autoconf renames sinclude to m4_sinclude via M4sugar.
I don't know why bare sinclude works for you; it does not work
for me.  If I replace sinclude by m4_sinclude, I can reproduce
your problem.

Odd...

When the first issue is cleared up, the second arises.  This is
what you are pointing out: m4_sinclude does not do dependency
tracking.

The way to fix this would be to make autom4te record which
optional (m4_sinclude) dependencies were present or absent on the
last run, so that it could update the target only if that state
changed.

My advice would be to use m4_include instead of m4_sinclude if
possible. 

I'm using sinclude here to include configure.in fragments from
plug-ins into the main configure.in. Some plugins are simple
enough not to need any configure.in checks, so they don't have
a fragment. I suppose I could force them all to have an empty
file and use include, but.
(In practice the workaround I've adopted is that we unconditionally
blow away the autom4te.cache before running autoconf since
we don't run autoconf unless configure.in or a fragment changed,
making the cache pretty useless.)

 Otherwise, if you'd like to implement the above
behavior and submit a patch to me, I'd be happy to review it,
include it in the Debian Autoconf, and submit to upstream.

I might have a look at this (although the internals of autoconf
are largely a mystery to me).

-- PMM


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#341263: autoconf doesn't realise its cache is out of date when included files change

2005-12-12 Thread Ben Pfaff
[EMAIL PROTECTED] writes:

 Package: autoconf
 Version: 2.59a-3

 Watch:

 ---begin---
 zircon$ mkdir test
 zircon$ cd test
 zircon$ cat configure.in
 AC_PREREQ(2.50)
 AC_INIT(test,1)
 AC_CHECK_FUNCS(wombat)
 sinclude(conf2.in)
 AC_OUTPUT()
 zircon$ autoconf
 zircon$ grep wombat configure
 for ac_func in wombat
 zircon$ grep baboon configure
 zircon$ cat conf2.in
 AC_CHECK_FUNCS(baboon)
 zircon$ autoconf
 zircon$ grep baboon configure
 zircon$ rm -rf autom4te.cache/
 zircon$ autoconf
 zircon$ grep baboon configure
 for ac_func in baboon
 ---endit---

There are at least two different issues here.  The first is
simply that Autoconf renames sinclude to m4_sinclude via M4sugar.
I don't know why bare sinclude works for you; it does not work
for me.  If I replace sinclude by m4_sinclude, I can reproduce
your problem.

When the first issue is cleared up, the second arises.  This is
what you are pointing out: m4_sinclude does not do dependency
tracking.  This is because, unless Autom4te actually records the
dependencies of a traced file that existed at the time, it has to
assume that a dependency that does not exist may be missing
because the file that included it was changed to no longer
include it.  Thus, a missing dependency always triggers an
update.   This interacts badly with m4_sinclude, which doesn't
yield an error if the dependency is missing.

The way to fix this would be to make autom4te record which
optional (m4_sinclude) dependencies were present or absent on the
last run, so that it could update the target only if that state
changed.  Autoconf 2.59 doesn't have any such logic, and a look
at Autoconf CVS shows that it hasn't been added there either.

My advice would be to use m4_include instead of m4_sinclude if
possible.  Otherwise, if you'd like to implement the above
behavior and submit a patch to me, I'd be happy to review it,
include it in the Debian Autoconf, and submit to upstream.  (I
have little interest in implementing this behavior myself.)
-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#341263: autoconf doesn't realise its cache is out of date when included files change

2005-11-29 Thread pmaydell
Package: autoconf
Version: 2.59a-3

Watch:

---begin---
zircon$ mkdir test
zircon$ cd test
zircon$ cat configure.in
AC_PREREQ(2.50)
AC_INIT(test,1)
AC_CHECK_FUNCS(wombat)
sinclude(conf2.in)
AC_OUTPUT()
zircon$ autoconf
zircon$ grep wombat configure
for ac_func in wombat
zircon$ grep baboon configure
zircon$ cat conf2.in
AC_CHECK_FUNCS(baboon)
zircon$ autoconf
zircon$ grep baboon configure
zircon$ rm -rf autom4te.cache/
zircon$ autoconf
zircon$ grep baboon configure
for ac_func in baboon
---endit---

Notice that the first autoconf creates a configure script which has a
check for 'wombat' but not 'baboon' (correctly, because at this point
conf2.in doesn't exist). We then create conf2.in, but rerunning autoconf
has no effect -- this is a bug. Blowing away the autom4te.cache causes
autoconf to do the right thing and update the configure script so it
includes the new check.

This seems to happen both for newly created included files (as in this
test sequence) and where a preexisting include file is updated.

-- PMM


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]