On 03-Dec-99 at 17:43, Dave Johnson ([EMAIL PROTECTED]) wrote: > On Fri, Dec 03, 1999 at 02:18:52PM -0500, Richard Gillilan wrote: > > Peter Daniel Kirchner wrote: > > > > > > Mystery solved! > > > > > > Those using non-"dist" sources (e.g. from cvs) and not using BOTH gcc > > > and GNU make need to run automake --include-deps > > > instead of > > > automake > > > > > > Per http://www.fsf.org/manual/automake/html_mono/automake.html#SEC29 > > > Automake's automatic dependency tracking currently requires the use of > > > both GNU make and gcc. make dist runs automake --include-deps to > > > remove the Gnu make + gcc requirement for the distribution. > > > We could also add "AUTOMAKE_OPTIONS = no-dependencies " to the > > > Makefile.am files, but that would preclude those who happen to be > > > using gcc and Gnu make from having dynamically updated dependencies. > > > whew! > > > pete > > > > > > > Jari's suggestion of using automake -a -i > > worked for me except that I had to edit > > one file (DXApplication.C) and override > > the following block of code: > > > > #if defined(OS2) || NeedNestedPrototypes > > int (*func)(Display *); > > #else > > int (*func)(); > > #endif > > > > The SGI compiler I'm using chokes on > > nested prototypes and needs the "else" > > option. > > > > I just restored the block above and > > did a clean remake using automake --include-deps. > > The makefile now works (as it did with -a -i), but > > the compile still chokes at DXApplication.C. > > > > I'm trying to track down where and how NeedNestedPrototypes > > is set. I'm new to all these autotools, so perhaps you can > > point me in the right direction. > > > > Richard > > I've been passing through the same steps today --- > > NeedNestedPrototypes is defined in the X11 configuration stuff. > The /usr/include/X11/Xlib.h provided on AIX 4.3.x has a prototype > for XSetAfterFunction which does not have a nested prototype in the > type of the return value (what is being assigned to "func" in > DXApplication.C). But NeedNestedPrototypes IS defined. > > Solutions??? > > 1) put an explicit cast between the assignment and the function call. > This forces the return value to be what it should have been if IBM and > SGI had gotten more recent X include files. > > 2) fix the include file on the system. Naahhh. > > 3) change NeedNestedPrototypes to > (NeedNestedPrototypes && !defined(_AIX) && !defined(SGI)) > or whatever is appropriate. > Yechh. This will fail when/if the Xlib.h is finally fixed. > > I think I am going to do #1 for now. > > I have other fixes in progress, mostly things that go wrong if you > do a checkout with CVSREAD: > > 1) in src/exec/dxmods/, there is no dependency to force building > of _compparse.h before trying to build _complex.o > Add _complex.o: _compparse.h line to end of Makefile.am.
This can be fixed simply by placing _compparse.y before _complex.c in the Makefile.am. Otherwise be very very carefull, you are getting into the details of the differences between bison and yacc. Automake does a pretty good job of things if you follow their instructions very carefully. > > 2) src/exec/dxmods has a copy of y.output checked into the tree. > Either fix Makefile.am to do -$(RM) y.output before running $(YACC), > or delete it from the tree. I think if you follow the automake instructions, all of these y.* files will not even get made, or made then renamed. In any case I highly recomend checking out the automake manual for flex/bison support. > > 3) several other places in the same Makefile.am, and in > src/exec/libdx/local.mk, "rm" is used without the -f option. > If cp (of a readonly file) results in another readonly file, this > becomes important, as in _plane.c and tmp.c. > Should use -$(RM) (which is defined with -f already) everywhere. > > -- ddj > > Dave Johnson > Brown University TCASCV > [EMAIL PROTECTED]
