Patrick:
> Ahhh, I love days without escalations at work ;-)
> So, actually Damien mentioned something to me yesterday about
> intltools which made me wonder something, so.. again some tests.
>
> Running the commands:
> m4 gok-with-references.schemas.m4 > gok-with-references.schemas.in
> ./configure --prefix=/tmp/bla --disable-gtk-doc
> make
>
> Actually gives the result you'd expect. mouse.kbd and friends in
> $(srcdir) + language directories but _no_ C directory with the kbd
> files in it.
That's interesting.
> So, what I did is comment the aclocal/autoconf and intoolize lines in
> gok.spec and you can guess the outcome, the build passed.
We do seem to be slowly narrowing down on this problem. Do you need to
comment out all three programs (aclocal/autoconf and intltoolize) for
the problem to go away? Can you check to see if you can narrow this
down further?
I wonder if the problem might be aclocal is picking up the wrong "m4"
files. There have been some issues lately where we need to set
ACLOCAL_FLAGS to "%{_datadir}/aclocal" in SUNWngome-a11y-gok.spec
so that getext.m4 is picked up from there instead of in an internal
m4 directory. I notice that in base-specs/gok.spec we call
"aclocal $ACLOCAL_FLAGS" but we do not set ACLOCAL_FLAGS anywhere.
Does it make a difference to change the order of the calls. Perhaps
intltoolize should be before the aclocal call.
> So, I am thinking, is Damien right in saying the bug/problem might be
> related to bumping intltools up last December (I see INTLTOOL_MERGE
> variables in autoconf.m4 for example)? And would it help when I
> provide the config.status/Makefile etc?
This problem started happening in Nevada build 78, which is
coincidentally the same build which automake/autoconf got integrated
into Nevada. I wonder if this change might have triggered this
problem.
Brian
