This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Documentation generation patch [Take 2]
On Fri, May 11, 2001 at 05:45:03PM -0700, Mark Mitchell wrote:
> >>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
>
> Joseph> We need to resolve the directory naming and where this
> Joseph> fits into the Makefile rules. Presumably the info files
> Joseph> get generated into the source doc directory? Do manpages
>
> Ack, no. Nothing should be generated in the source directory. The
> fact that bison-generated files go there, for example, is, in my
> opinion, a bug.
Note that things which are generated into the source directory are,
paradoxically, one of the major issues preventing source==build
configuration. (The rules which generate things into $(srcdir) get
get confused if $(srcdir) == $(objdir). Make clean can also get
confused and delete too much.)
It is my personal opinion that the requirement to ship Info files with
release kits is obsolete; if you want to install them from source you
should have makeinfo handy.
For the other generated+shipped files, my suggestion would be: The
rules invoked by a normal build are autoconf-conditionalled on the
existence of the appropriate tools, either to run those tools with
output to the build directory, or to copy pre-rolled versions from the
source directory. There is a non-default rule which generates
everything that's generated with exotic tools, into the source
directory, unconditionally. The tarball-generation scripts run this
target.
> Joseph> Tangentially related: is there an official position for
> Joseph> 3.0 on whether non-GNU make is or is not supported, and
> Joseph> whether building in the source directory is or is not
> Joseph> supported?
>
> Non-GNU make is (empirically) not supported. We've argued about this,
> and it looks like I won, sort-of by accident. There are now
> constructs that only work with GNU make.
Last I tried it, pmake worked just fine. Unfortunately, pmake is
Debian's port of *BSD make, and it's a hybrid of of all three BSD
trees, so this does not necessarily indicate anything about what
happens if you try a build on a *BSD host using its /usr/bin/make.
It is my personal opinion that requiring GNU make would be a long-term
Good Thing, because we could stop worrying about working around broken
vendor make implementations. Also, some judicious use of gmake
extensions could drastically simplify the Makefiles - e.g. we could
easily have automatic dependency generation. (I have some ideas how
to do it anyway, but don't hold your breath for the patch.)
--
zw ...It's not easy for cognitive scientists to get grants if they
are working on questions of any theoretical interest. (To ensure
this is a main function of the institution of peer review.)
-- Jerry Fodor, _The Mind Doesn't Work That Way_