Date: Thu, 19 Aug 1999 14:19:16 +0100 From: Nik Clayton <nik@freebsd.org> To: doc@freebsd.org Subject: docproj.docbook.mk cruft, naming, splitting Message-ID: <19990819141916.A36423@kilt.nothing-going-on.org>
next in thread | raw e-mail | index | archive | help
How do,
As per my earlier message, consider this a request for comments. I'm not
going to implement anything yet, but would like to implement something
soon. . .
I think it would be nice if the FDP Makefile's drew from, but did not
depend on, the system make files in /usr/share/mk. It would be nice if
doc/ was completely self contained, so that you could download it on to
pretty much any FreeBSD system and have it build (as long as the
appropriate apps are in place).
Don't get me wrong -- I think we can still lever a lot of the work that's
gone in to the bsd.*.mk files, and I think we should. But having
doc/share/mk/fdp.own.mk
fdp.docbook.mk
fdp.install.mk
fdp.subdir.mk
and so on makes it simpler to transport the doc tree to other systems.
Ultimately, all you should need to move is doc/<lang>/* and doc/<share>/*.
Of course, for some of these files it makes sense if they get their
default values from the system files. For example, a hypothetical
fdp.own.mk might start with
.if exists(bsd.own.mk)
.include <bsd.own.mk>
.endif
to pick up definitions for the system DOC* variables, but still allow us
to override them (or provide defaults if bsd.own.mk isn't available for
some reason).
This also makes it possible to drop our doc tree on to a foreign OS
(Solaris and Linux are the most popular requests I've been getting) and
build it there (assuming they have a Berkeley Make available -- see my
recent DaemonNews columns for instructions on how to get a bmake for
other systems).
I imagine it would make things easier for the *BSDs as well, should they
wish to use our work.
Another compelling reason to do this is that the existing docproj.docbook.mk
is rapidly becoming too large, and is requires DOC_PREFIX to be set before
you can .include it in other Makefiles -- this is a pain (see my recent
(or shortly to happen)) commits to doc/<lang>/Makefile to see where this
is necessary.
I can't think of a compelling reason not to put this on the list of things
to do. Can anyone think otherwise?
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom Christiansen in <375143b5@cs.colorado.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990819141916.A36423>