Red Hat Bugzilla – Bug 127117
missing m4 macros
Last modified: 2007-11-30 17:10:45 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: Please contains some m4 macros which is distributed by the upstream. it's useful to develop LEs and helps to check something in configure script. plus, when iiimf-le-inpinyin do autotoolize again, those m4 macros are required. so including it into the package makes sense. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.for i in `rpm -qa | grep iiimf`; do rpm -ql $i | grep m4; done 2. 3. Actual Results: missing m4 macros Expected Results: it should be included in the -devel package somewhere. Additional info:
I took a look
[oops] I took a look at the .m4 files and found that they're all named config_*.m4 and also look pretty im-sdk specific so I don't think it is appropriate to include them all as in in /usr/share/aclocal. So my suggestion is to either include them as is in the doc dir for iiimf-libs-devel or merge them all into one file (say iiimf.m4).
that's one of solution, but I don't think it may confuses people, because actually merged m4 files, I mean that one file isn't shipped from upstream. say, people saw that file, and ask upstream about something like related that file. Instead, how about making the subdirectory like gnome-common does? ah, we haven't shipped it. ok. well, gnome-common installs the m4 files under /usr/share/aclocal/gnome{,2}-macros, and autogen.sh refers those m4 files with -I option for aclocal. including them in the doc dir isn't a good idea, because rpm makes the versioned doc dir. and the developer needs to be run aclocal with -I option anyway. but it depends on the specific version or needs to use the wildcard to build it.
We could ask upstream to merge them into one file, I suppose. Shall we put them in /usr/share/aclocal/iiimf for now then? I haven't looked at them very carefully, but just the naming of the files and their macros on a quick look made me wonder a little about their quality though bicbw: that is why I suggested to put them in doc since then people could easily copy'n'paste what they need into their project's .m4 file.