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?
I'm not sure which system-wide .m4 directory you mean. I didn't get one with the installation of either m4 or autoconf, as far as I'm aware. share/autoconf/*/*.m4 is autoconf internal files. share/aclocal is for files intended to be picked up by aclocal, and you can't even rely on it's existance unless you make pike depend on automake, which I think would be unnecessary and unfortunate.
Neither is the right place for pike's aclocal.m4.
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?
You can use automake, but then you will not use pike -x module. And it makes no sense to have aclocal pick up the aclocal.m4 which is intended for use with pike -x. I don't know for sure that it doesn't work to do that (as I haven't tried), no matter if it ever works it's an utterly unsupported way to use that file. It's on par with including files from pike/lib/include/ into C programs.
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.
My point is that debian automake policy should be applied only to the installation of files which are intended to be used with automake, or are in some other way closely related to automake. The pike package does not contain a single file that is intended to be used with automake; therefore automake policy is not relevant to the pike interpreter package.
/ Niels Möller (vässar rödpennan)
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
And, again, nothing stops people from writing a pike.m4 (or perhaps pike7519.m4, with a symlink to pike.m4 from the last installed version, in the spirit of previous arguments about not trying to support multiple pikes from the same .m4-file) that is actually intended to be used from automake (that file would probably not be all that similar to the current aclocal.m4, though.)
Doing so would only be good, since it would help people who use automake, and not break things for people who use pike -x module.
/ Per Hedbor ()
Previous text:
2004-01-26 22:50: Subject: Re: Pike @ Debian
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?
I'm not sure which system-wide .m4 directory you mean. I didn't get one with the installation of either m4 or autoconf, as far as I'm aware. share/autoconf/*/*.m4 is autoconf internal files. share/aclocal is for files intended to be picked up by aclocal, and you can't even rely on it's existance unless you make pike depend on automake, which I think would be unnecessary and unfortunate.
Neither is the right place for pike's aclocal.m4.
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?
You can use automake, but then you will not use pike -x module. And it makes no sense to have aclocal pick up the aclocal.m4 which is intended for use with pike -x. I don't know for sure that it doesn't work to do that (as I haven't tried), no matter if it ever works it's an utterly unsupported way to use that file. It's on par with including files from pike/lib/include/ into C programs.
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.
My point is that debian automake policy should be applied only to the installation of files which are intended to be used with automake, or are in some other way closely related to automake. The pike package does not contain a single file that is intended to be used with automake; therefore automake policy is not relevant to the pike interpreter package.
/ Niels Möller (vässar rödpennan)
Couldn't agree more. Anybody who knows and likes automake and wants to use it for building external pike modules is welcome to design and implement a recommended procedure for doing that.
And such a project is mostly orthogonal to pike -x module and to the current aclocal.m4 and its installation.
/ Niels Möller (vässar rödpennan)
Previous text:
2004-01-26 22:55: Subject: Re: Pike @ Debian
And, again, nothing stops people from writing a pike.m4 (or perhaps pike7519.m4, with a symlink to pike.m4 from the last installed version, in the spirit of previous arguments about not trying to support multiple pikes from the same .m4-file) that is actually intended to be used from automake (that file would probably not be all that similar to the current aclocal.m4, though.)
Doing so would only be good, since it would help people who use automake, and not break things for people who use pike -x module.
/ Per Hedbor ()
pike-devel@lists.lysator.liu.se
-
Niels M�ller (v�ssar r�dpennan) ＠ Pike (-) developers forum -
Per Hedbor () ＠ Pike (-) developers forum