No, we do not ignore external modules. But the current aclocal.m4 does not have anything to do with what you want (pike.m4 for automake/aclocal). Thus it's not sensible to 'clean it up' and install it as such.
Writing a pike.m4 would, however, make sense.
/ Per Hedbor ()
Previous text:
2004-01-26 22:18: Subject: Re: Pike @ Debian
On Mon, Jan 26, 2004 at 09:45:04PM +0100, Niels Möller (vässar rödpennan) @ Pike (-) developers forum scribbled:
Alas, it wouldn't... If some Pike C module runs aclocal it could pull in both the pike's aclocal.m4 and other files with, possibly, macros that are already defined in the pike's aclocal.m4 file. I doubt autoconf is smart enough to cope with it ;)
I think you're confusing several things here. Autoconf, automake, the aclocal program (more or less a part of automake), and the aclocal.m4 file are not all used together and are not using the same conventions.
Believe or not, but I'm quite aware of that. Let me remind you that the proposition was to put the pike's aclocal.m4 under a different name in the system-wide .m4 directory. Does that change your assessment?
aclocal.m4 existed long before automake, and it plays the same role that acinclude.m4 plays in automakeified projects. It's a *handwritten* file included by autoconf, specific to the project being built.
Again, I'm quite aware of the fact.
The aclocal proram is a later invention that constructs an aclocal.m4 file from various fragments stored somewhere under share.
You haven't surprised me here, either.
Pike uses autoconf, and uses aclocal.m4 the the way it was intended when autoconf was first written. It does *not* use automake, and it does *not* use the aclocal program. It's aclocal.m4 is *not* intended to ever be picked up by the aclocal program.
It does *not* mean the external Pike modules written in C _cannot_ use automake, am I right? Or is it forbidden because Pike itself doesn't use it?
So the main poitn here is that any debian policy that has to do with automake and the aclocal program is totally irrelevant to pike.
Of course it isn't. But it might be relevant to external Pike modules. But you're determined to ignore them, right?
marek
/ Brevbäraren