>>> "Thomas" == Thomas Vander Stichele <[EMAIL PROTECTED]> writes:
[...] Thomas> In most cases you use the .m4 macro installed with the Thomas> -devel package of the library. Since we cannot expect Thomas> every GStreamer developer to have all libraries and Thomas> -devel packages that could possibly used with it, we Thomas> ran into problems. If you use the macros from these Thomas> -devel packages but you don't ship them, the autotools Thomas> will complain about undefined macros and this stumps Thomas> users. Thomas> So we started shipping .m4 files from these libraries Thomas> in a separate .m4 directory. People have advised Thomas> against this but I don't really know how to solve this Thomas> otherwise. I had one idea though, but I don't know if Thomas> it's possible : if there's a way to check if a macro is Thomas> already AC_DEFUN'd or not, I could implement fallback Thomas> macros that tell the rest of the configure not to Thomas> enable this plugin. I don't know if that's possible or Thomas> not ? ... and whenever you make a new release you will have to make sure those fallback macros have not been used accidentally? IMHO, it's not worth the trouble, just ship the macros you use. Doing so also allows one developer to make a fully-usable release without having all the optional packages installed. Thomas> Anyway, what I also wanted to ask was: is it better to do Thomas> cat m4/*.m4 > acinclude.m4 Thomas> or Thomas> aclocal -I m4 ? Thomas> In the second case, people get warnings that certain Thomas> macros are defined twice (since, for example, they have Thomas> the right .m4 on their system from their devel package, Thomas> and we supply another version of it). This was the behavior of Automake 1.4. This is no longer the case today. Thomas> I'd like to avoid that of course, so I use the first Thomas> method. Thomas> The first method seems to have the disadvantage that it Thomas> prefers our supplied m4's, while it would be better to Thomas> prefer system-installed m4 macros. aclocal will prefer the local m4/ macros over the system macros too. I fail to see why this is bad, but if it annoys you it's easy to order the -I options to that effect: aclocal -I `aclocal --print-ac-dir` -I m4 [...] -- Alexandre Duret-Lutz
