Macro Format (was: bnv_have_qt: QT_CXXFLAGS ...)

[Peter Simons]

Guido Draheim writes:

 >> (a) Abandon XML altogether and go back to the @keyword
 >> style of adding meta information. The HTML page
 >> generated for your macro wouldn't look as good anymore
 >> as it does now, but that's not exactly a major concern.

 > That's a matter of parsing the content, the @description
 > block is currently not expected to contain direct html
 > text but one can easily enable that.

Right. Technically that's no problem at all, the software
would just "stop" quoting HTML specials, and then you could
embed HTML into the description. The downside is that you'd
have to write '&lt;' instead of '<' and '&amp;' instead of
'&'.

And, of course, you'd have to deal with bogus HTML. ;-) The
HTML pages we generate right now are _all_ perfectly valid.
I'm not sure how much that's worth, though.


 > I won't like to see xml being abandoned altogether - it's
 > a very good intermediate format that can combine many
 > sources much more easily than trying to do it with a
 > bunch of scripts.

I agree. Also, XML allows us more sophisticated
meta-information. One thing that has been missing ever since
is the notion of "packages". XML also comes with all kinds
of mechanisms to express cross-references and dependencies.

In case any cares, the DTD is here:

  http://www.gnu.org/software/ac-archive/dtd/acmacro1-xml.dtd


 >> (b) Commit a pseudo-macro in the legacy tree that tells the
 >> user to go to www.gnu.org/.../bnv_have_qt.html for the
 >> real thing.

 > Only if the text is being auto-generated from the xml
 > source, ... as things would get out of sync sooner than
 > later.

No problem, I could mirror all XML macros into the legacy
tree automatically. The only question is whether we'd want
auto-generated files to be committed into the CVS tree,
especially if they don't do anything. I wouldn't mind overly
much, but it raises the question of how far we'd like to go
to keep sf.net "in sync" with gnu.org. I'd much rather like
to integrate sf.net's added features (like RPMs, etc.) into
gnu.org, so that we don't need two archives any longer.


 > Yeah, it's a long story. Btw, where do you have the
 > sources to the formatting engine of yours?

I never released the engine because it's (a) written in
Haskell and not many people could run that to begin with and
(b) because of that long story we won't retell. ;-)

If there is an interest, I could make the sources available.
It's just a fairly complex installation, because you need a
Haskell compiler, an SGML (or XML) parser, and lot's of
secondary tools. So it may turn out to be quite an effort to
set it up. I'd help where I can, naturally. It would be
pretty cool to find someone who can regenerate and maintain
the archive too, I have too little time to respond quickly
more often than not. I'd be all for it. :-)


 > As claimed earlier I am pretty unambitious about web
 > presentation things with my focus being more on packaging
 > and maintaining an `acinclude` tool.

What changes would need to be made to the gnu.org archive to
make your packaging tools work? I'd really like to provide
better releases and a way to "install" the macros.

Peter