This is the mail archive of the gcc-patches@gcc.gnu.org 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 <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_


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