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]
