In theory, I think the best way is to do as follows:
When hacking XML2-support (or whatever support) for pike, copy the XML2-recommended m4 macros into aclocal.m4 or some other file included into configure.in in one way or another. Check all that into the Pike cvs.
configure.in should be system independent, and should use the same macros no matter if XML2 happens to be installed at buildtime or not.
Is there any reason that can't work?
/ Niels Möller ()
Previous text:
2002-08-29 22:42: Subject: Autoconf macros and aclocal
Guys, what's the policy about using the aclocal .m4 macro files provided with some libraries (like GTK+, XML2 etc.)? Should I include the macro in the src/aclocal.m4 or just put the AM_* macro right in the configure.in and rely on the .m4 file presence on the system where Pike is compiled/exported?
/ Marek Habersack (Grendel)
The drawback with that approach is that bug fixes and extensions to the m4 macros in the upstream source doesn't get used unless someone manually updates them in pike. I don't think it's a problem to use them directly; we must probably ensure that the machine(s) that build the distributed source dists have a complete build environment anyway. The problem is rather to recover gracefully when someone builds from cvs for personal use on an incomplete system.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-30 15:50: Subject: Autoconf macros and aclocal
In theory, I think the best way is to do as follows:
When hacking XML2-support (or whatever support) for pike, copy the XML2-recommended m4 macros into aclocal.m4 or some other file included into configure.in in one way or another. Check all that into the Pike cvs.
configure.in should be system independent, and should use the same macros no matter if XML2 happens to be installed at buildtime or not.
Is there any reason that can't work?
/ Niels Möller ()
Do you think that's a real problem? The macros distributed with version foolib-1.17 ought to work with some older and later foolib versions (e.g by the popular method of invoking some foo-config program).
If a later version of foolib makes incompatible changes to the detection mechanism so that the old macros won't work, that can be dealt with just like other incompatible changes in the library which happen from time to time.
And if foo-config compatibility breaks a lot more often then foo-compatibility in general, then the natural conclusion is that the advertised m4 macros are broken and one's probably better off writing one's own macros.
/ Niels Möller ()
Previous text:
2002-09-30 17:49: Subject: Autoconf macros and aclocal
The drawback with that approach is that bug fixes and extensions to the m4 macros in the upstream source doesn't get used unless someone manually updates them in pike. I don't think it's a problem to use them directly; we must probably ensure that the machine(s) that build the distributed source dists have a complete build environment anyway. The problem is rather to recover gracefully when someone builds from cvs for personal use on an incomplete system.
/ Martin Stjernholm, Roxen IS
No, I don't think it'd be that common that they change, but various minor fixes could nevertheless be nice to get automatically. It should be weighted against the cost (and will) to implement a way to recover, and it seems fairly simple to do it. I don't know how far Marek got in actually doing it, though.
Anyway, I think it's clearly better to have a system that avoids manual duplication than one that don't.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-30 23:06: Subject: Autoconf macros and aclocal
Do you think that's a real problem? The macros distributed with version foolib-1.17 ought to work with some older and later foolib versions (e.g by the popular method of invoking some foo-config program).
If a later version of foolib makes incompatible changes to the detection mechanism so that the old macros won't work, that can be dealt with just like other incompatible changes in the library which happen from time to time.
And if foo-config compatibility breaks a lot more often then foo-compatibility in general, then the natural conclusion is that the advertised m4 macros are broken and one's probably better off writing one's own macros.
/ Niels Möller ()
What I'd really want is a decent modulesystem for autoconf, as an alternative to using automake's aclocal stuff.
/ Niels Möller ()
Previous text:
2002-09-30 23:15: Subject: Autoconf macros and aclocal
No, I don't think it'd be that common that they change, but various minor fixes could nevertheless be nice to get automatically. It should be weighted against the cost (and will) to implement a way to recover, and it seems fairly simple to do it. I don't know how far Marek got in actually doing it, though.
Anyway, I think it's clearly better to have a system that avoids manual duplication than one that don't.
/ Martin Stjernholm, Roxen IS
Also in some cases it might be agains the OS policy (yes, I'm referring to Debian :) where the package should use the stuff provided by other packages if the item it uses belongs in that other package).
/ Marek Habersack (Grendel)
Previous text:
2002-09-30 23:15: Subject: Autoconf macros and aclocal
No, I don't think it'd be that common that they change, but various minor fixes could nevertheless be nice to get automatically. It should be weighted against the cost (and will) to implement a way to recover, and it seems fairly simple to do it. I don't know how far Marek got in actually doing it, though.
Anyway, I think it's clearly better to have a system that avoids manual duplication than one that don't.
/ Martin Stjernholm, Roxen IS
pike-devel@lists.lysator.liu.se
-
Marek Habersack (Grendel) ＠ Pike (-) developers forum -
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Niels M�ller () ＠ Pike (-) developers forum