This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: top level: make more dependencies explicit
- From: Nathanael Nerode <neroden at doctormoo dot dyndns dot org>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, gdb at sources dot redhat dot com,binutils at sources dot redhat dot com, dj at redhat dot com
- Date: Sun, 29 Sep 2002 15:01:00 -0400
- Subject: Re: top level: make more dependencies explicit
- References: <20020929165232.GA27545@doctormoo.dyndns.org> <3D9733C2.2010405@redhat.com> <20020929172608.GA27678@doctormoo.dyndns.org> <3D973C44.6090601@redhat.com> <20020929174544.GA30373@doctormoo.dyndns.org> <3D974828.4050009@redhat.com>
On Sun, Sep 29, 2002 at 02:36:24PM -0400, Andrew Cagney wrote:
>
> >>The mechanism is very old (it pre-dates me as GDB release engineer).
> >>Changing it is going to involve updates to many things - snapshot
> >>scripts, release process doco, .... so won't happen overnight.
> >
> >
> >Mmmm. I'm going to start rewriting it now. >:-=
>
> What does the GNU coding standard have to say about the release process?
>
> I'd also be wary of a ``rewrite'', the top-level stuff iteracts with
> sub-directories in strange ways. I think reserving the existing
> behavior (but perhaphs outside of the Makefile.in) would be a better
> incremental step.
>
> Also, how does this compare to GCC's release process.
GCC has an entirely separate set of scripts for release generation.
Incidentally, I think I have a rewrite which works already... I'm busily
generating a gas.tar.bz2 to see. But I'm not going to submit it at the
moment, since it needs oodles of testing.
Is the setting of SHELL the only problem with using Makefile.in as a
Makefile? It looks like none of the others matter, in which case I'd
like to bring them back.