Merging old man pages

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

We've now got a viable mechanism for generating man pages from sgml
sources.

Excellent!

From here on, there is no need to update the src/man/ man pages when
updating docs. Please do all updates in doc/src/sgml/{.,/ref}/*.sgml.
I'll be removing the old man pages from the cvs tree,

OK, let me get this straight: man pages will no longer be in the CVS
tree because they will no longer be original files, but they will be
part of the standard distribution as derived files, right?

regards, tom lane

OK, let me get this straight: man pages will no longer be in the CVS
tree because they will no longer be original files, but they will be
part of the standard distribution as derived files, right?

Yes. Well, at least, maybe, sort of...

As is the case with the other (html) docs, I'm planning on putting a
man tarball into the distribution. Up to now, the easiest way to do
that is to put the tarball into cvs, but I'm open to other
suggestions.

Do I guess correctly that we currently generate our production
releases by actually doing a cvs checkout and then a "mini-build" of
the system to generate the yacc/bison derived files? If so, we could
consider doing the same sort of thing for the html and man products,
but it (probably) makes this packaging process more fragile.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Do I guess correctly that we currently generate our production
releases by actually doing a cvs checkout and then a "mini-build" of
the system to generate the yacc/bison derived files?

Right.

If so, we could
consider doing the same sort of thing for the html and man products,
but it (probably) makes this packaging process more fragile.

Less fragile than doing it by hand ;-). I'd say that's exactly the
way to proceed.

The shell script src/tools/release_prep contains the commands that
are executed (at hub.org) to prepare derived files for release.
Add whatever is needed to build the derived doc files, and we should
be set.

regards, tom lane

Thomas,

I'm interested in the new mechanism. Where can I find more detail about
it?

Thanks,
Fred H.

You wrote:

I'm interested in the new mechanism. Where can I find more detail
about it?

I believe that I wrote a small bit about the setup in the latest docs
appendix on "Documentation". Look on the web site or on
ftp://postgresql.org/pub/docs/postgres.tar.gz

Basically, to get this working on my Linux box I had to install a perl
package from CPAN and then reuse some routines I already had from my
jade installation (which builds the main docs).

If you want to try it, you will need to get my patched version of the
processing script. The original author has said that he will take most
of my patches, but I'm not sure how that will turn out. In any case,
I'll post these tools on postgresql.org sometime soon.

If you want to get started earlier, let me know and I'll send some
files...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Thomas,

Thanks for the info. The documentation tools are indeed nicely
described at http://www.postgresql.org/docs/postgres/docguide.htm.

Thomas Lockhart wrote:

I'm interested in the new mechanism. Where can I find more detail
about it?

I believe that I wrote a small bit about the setup in the latest docs
appendix on "Documentation". Look on the web site [...]

If you want to try it, you will need to get my patched version of the
processing script. The original author has said that he will take most
of my patches, but I'm not sure how that will turn out. In any case,
I'll post these tools on postgresql.org sometime soon.

That would be great. I'll wait till then.

Fred H.