This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Documentation generation patch [Take 2]

On Fri, May 11, 2001 at 05:45:03PM -0700, Mark Mitchell wrote:
> >>>>> "Joseph" == Joseph S Myers <> 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

>     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_

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]