On 22/05/06, Aaron Spike <aaron@...749...> wrote:
Bryce Harrington wrote:
This is a critical step for being able to start doing pre-releases during the bugfix phase, so any help on getting make distcheck to pass will be very important.
Sorry I carelessly replaced the URL Bryce linked above. I guess that is ok, because my problem with distcheck changed. Now I getting the long strand of "What GTK?" type errors similar to those seen below. This error resulted from the changes Ralf made in revision 11886. It looks harmless enough to me, but now I can't even build autopackages.
http://svn.sourceforge.net/viewcvs.cgi/inkscape/inkscape/trunk/configure.ac?...
This is a good point. When I saw that a change to configure.ac had been made, I ran ./autogen.sh to create an up-to-date configure.in (this advice may need to go into the CompilingMacOSX page); I am fairly sure that make's dependency tracking does not check whether configure.in is out of date and would not know how to re-create it anyway. You may want to check the autoconf docs about this.
(and I repeat my apology concerning grandmaternal ovafrages).
I think that the autoconf folk assume that developers using configure.ac can work this out for themselves, which is not altogether unreasonable, but fails to take into account the fact that most of us like to treat it as a black box and that it may not be true that everyone working from checked out sources is an expert. Perhaps this is the main mission of 'make distcheck' - to check that the distribution tarball is complete.
If we could get a couple people to run `make check` and `make distcheck` and start resolving or even just reporting the problems, that would be super.
Oh and has anybody else noticed this?
$ make clean $ svn up Restored 'po/inkscape.pot'
Should make clean remove a file stored in SVN? Rather should a generated file removed by make clean be stored in svn?
It is not my pigeon, but I suspect that your second suggestion applies. There is nothing really wrong with committing generated files (though some people frown on it), but one should be selective. For example, if one wishes to encourage 'occasional' developers to compile from svn then the ./configure script should be in svn even though regular developers will use autoconf to generate it afresh.
(I don't do 'make clean' all that much, either!).
Aaron Spike
make[2]: Entering directory `/usr/local/src/inkscape/ap/src' if apg++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/local/src/inkscape/extra/static//include/loudmouth-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -DPOTRACE="potrace" -I/usr/local/src/inkscape/extra/static/include/sigc++-2.0 -I/usr/local/src/inkscape/extra/static/lib/sigc++-2.0/include -I../cxxtest -I/usr/local/src/inkscape/extra/static/include -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -O2 -march=i586 -pipe -MT arc-context.o -MD -MP -MF ".deps/arc-context.Tpo" \ -c -o arc-context.o `test -f 'arc-context.cpp' || echo './'`arc-context.cpp; \ then mv -f ".deps/arc-context.Tpo" ".deps/arc-context.Po"; \ else rm -f ".deps/arc-context.Tpo"; exit 1; \ fi arc-context.cpp:21:28: error: gdk/gdkkeysyms.h: No such file or directory
I think that this means that make cannot find your gtk include directory. Looking at the above, I would guess that you have a directory /usr/include/gtk-2.0 (mine is /sw/include/gtk-2.0/) and that there are a pair of -I flags missing, cognate to the ones for glib-2.0. I would hazard a guess that either ./configure did not run properly. or more reasonably, that it was missing something that should enable it to find your required gtk.
You may want to track down why (if this is the case) ./configure works correctly when called by hand, but not when called by 'make distcheck'. (If you are using the -k flag you may have told 'make distcheck' to carry on regardless after an unsuccessful ./configure; in which case you may have to scroll back a bit to find any errors reported by ./configure). You may find that ./configure left a 'config.log' which will almost certainly be helpful here.
I may be getting into tiger country, but I would be tempted to review the pkg-config installation, perhaps with a command like:
$ pkg-config --cflags gtk
You get the idea.
Please post again if you think I can help, but I don't claim unusual expertise!
Ben