Jared Casper wrote: > I noticed you removed version.texi with the comment that "you have all > the tools and makefile rules for them to be regenrated anyway." So am > I missing something? "make version.texi" in the doc directory claims > "Nothing to be done for 'version.texi'." and there is no version.texi > in the directory. A glance at the generated Makefile in doc and there > is only one rule explicitely for verison.texi: > '$(srcdir)/version.texi: # $(srcdir)/stamp-vti'. uncommenting the > dependency makes the build succeed, but I don't know enough about the > doc building system to know if that is the right thing to do (or how > to prevent it from being there, starting from the .am).
this is related to maintainer mode, more on this coming.... > > Another interesting thing to note is that when building in a seperate > build directory (not in the source tree), with the source tree in > ../pcb-clean, it says 'makeinfo: Removing output file > `../../pcb-clean/doc/pcb.info' due to errors; use --force to > preserve.' i.e. it appears to be making pcb.info in the source > directory rather than the build directory, which seems wrong. Most > other generated stuff (*_size.texi, .png's, .gif's, and .pdf's) are > correctly generated in the build/doc directory. > yep. more on that.... > Also, 'make distclean' removes > doc/{fractional_size,letter_size,metric_size,wire_size}.texi and > po/pcb.pot, which are tracked by git. Seems like all these are > generated files that can be removed from git (along with the others, > like version.texi, that you removed). yes, I will remove those. Thanks for catching them. > > Let me know if there is anything I can do to help (or if I missed > something?). I may look at it more in depth later on tonight, to try > to figure out the "right" solution, if I get a chance ok, here is what I have found. if AM_MAINTAINER_MODE is given in the configure.ac file (which it still is), it causes 2 primary things to happen. 1) dependency rules for rebuilding configure, Makefile.in's, aclocal.m4, etc are enabled. In non-maintainer mode, if you happen to edit Makefile.am, then you have to explicitly ask for automake to be re-run. In maintainer mode, thats just a rule. 2) the rule for building version.texi is conditionalized on --enable-maintainer-mode These 2 things are built into automake and not something I've done. There seem to be 2 schools of thought about having a maintainer mode at all. Some feel that we should never disable the Makefile.in: Makefile.am rule. After all, Makefile.am is the source file and Makefile.in is an intermediate generated file. I largely agree with this. The second school of thought is if you're not a maintainer then you should never want to run automake, aclocal, autoconf, etc yourself and thus you should avoid these rules ever being triggered. For users with slower machines, this can be welcomed and it has seemed to me like these rules get triggered spuriously sometimes. So we have 2 options that I've tested and both seem to work. 1) remove AM_MAINTAINER_MODE 2) now that we can detect if we're building from git sources then if we are building from git sources and we are building the docs then forcefully enable maintainer mode (along with a message so the user knows what has happened). I think I can go either way and would be curious about other opinions (opinions including some justification as to why). With regards to pcb.info being built into $(srcdir) instead of the build directory, that is a consequence of the GNU coding standards which say .info files go into the distribution and it evidentially is a pain for automake to do this if the .info file is created somewhere else. This is the response I have seen several times in the automake list archives when this very question came up. Now the final issue I've found is that the way version.texi is created (and this is fully contained within automake) seems wrong to me. It gets its last modified/updated time from pcb.texi but ignores the fact that pcb.texi has include statements that pull in things like the file format, actions reference, drill table, etc sections of the manual from other files. So to get the correct info in version.texi for a release you almost have to gratuitously touch pcb.texi just to update the time stamps. But... this issue takes a back seat in my mind towards fixing the problems people have had with building docs once and for all. -Dan _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user