On Sat, 2006-01-07 at 07:47 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" <stickster@xxxxxxxxx>, spake thus:
> > As long as there's a way to share common files like figures under a
> > common/ subdirectory we should be OK. I'm sure Tommy will think about
> > this and propose something logical.
> Oh, foolish mortal! I did think of this (check the archives), back
> when we first started added the i18n build support. The consensus at
> the time was to have flat directories. And so we do.
Ha! I don't know about you, but I plan to live forever. ;-D
> \-- example-tutorial/
> +-- Makefile
> +-- common/
> | +-- Makefile
> | +-- bin/
> | +-- figs/
> | +-- src/
> | \-- xml/
> \-- en/
> +-- Makefile
> +-- bin/
> +-- figs/
> +-- src/
> \-- xml/
> bin/ holds whatever scripts and such that need be run to
> generate dynamic content.
> figs/ holds language-specific diagrams and whatnot, such
> as SVG files converted to PNG by a bin/ script.
> src/ holds any raw code or snippets needed for the
> figures or examples. I use this to make sure any
> code-based screenshots actually work.
> xml/ Holds the XML files for the document. Does not
> usually have subdirs, but they are not prohibited.
> A set of recursive Makefile's tie all this together, so I can drive
> everything from the top-level Makefile.
> Now, most of this is overkill for FDP, but I believe the structure is
> comprehensible, scalable, and most of all "sound". Any subdir not
> needed can simply be omitted. More could be added.
Now *that's* what I'm talkin' 'bout.
> Seriously, this would simplify the individual Makefile's even more than
> what we currently have, because we could avoid all those silly Makefile
> TEMPLATE constructs: they're elegant but not really readable.
OTOH, if we'd never used them I wouldn't have learned how they work. :-)
> I propose deferring this reorganization until we get the RPM
> packaging stuff nailed down. Then we can just change the paths
> around a bit ;-)
Agreed, but I think we need some "thirds" and "me too's" before
proceeding since it will shake up CVS a little. *sigh* If only we used
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
fedora-docs-list mailing list