On Mon, 2007-10-08 at 10:12 +0100, Christopher Key wrote:
[snip]
> For now, the documentations gets built directly into the source tree,
> and the relevant build commands in doc/Makefile.am. I'm not terribly
> happy with this as a long term solution though, it seems intuitively
> wrong for the source tree to be modified when during a build process
> performed in a distinct build tree.
Note that's exactly what happens when you modify Makefile.am;
Makefile.in gets automatically regenerated in srcdir.
For builds from distribution tarballs, I agree that modifying stuff in
srcdir should be off limits. But for developer builds, I think a bit
more flexibility is called for.
> I have to admit that seperating out the build step for the documentation
> hadn't occured to me, it does seem cleaner in some ways, but there you
> do lose the ability to automatically rebuild the documentation when
> required. As a compromise, I think I may add create a doc/builddocs.sh
> script, that gets called both from my autogen.sh and from
> doc/Makefile.am. This way, the source tree shouldn't get modified
> during a build unless it needs to.
You may want to have a look at what I do for OpenVRML:
<http://openvrml.cvs.sourceforge.net/openvrml/openvrml/doc/Makefile.am?revision=1.37&view=markup>
It works reasonably well, but with the weakness that you note: 'make
dist' won't automatically rebuild the docs if they are out of date. I
haven't figured out a solution for that.
> Dealing with unknown sets of files does seem particulary easy. At the
> moment, I've only got html documentation, and have borrowed FLAC's
> system, in which the install and uninstall sections are coded manually
> (i.e. cd html/api && install * ...). Is there any chance that autoconf
> / automake might be extended to allow wildcar substitution somehow, e.g.:
>
> dist_man_MANS = man/*.[1-9]
>
> I guess that these would have to be expanded out by autoconf rather than
> configure.
Wildcards work in EXTRA_DIST. I've also used them successfully in my own
install-data-local rule.
--
Braden McDaniel e-mail: <braden@xxxxxxxxxxxxx>
<http://endoframe.com> Jabber: <braden@xxxxxxxxxx>
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
