Re: gEDA-user: PCB build changes

[Dan McMahill <dan@xxxxxxxxxxxx>]

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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user