Re: top level: make more dependencies explicit

Re: top level: make more dependencies explicit

[Nathanael Nerode]

On Sun, Sep 29, 2002 at 01:45:40PM -0400, Andrew Cagney wrote:
> >On Sun, Sep 29, 2002 at 01:09:22PM -0400, Andrew Cagney wrote:
> >
> >>Nathanael,
> >>
> >>FYI, I'm about to revert this change:
> >>
> >>2002-09-25  Nathanael Nerode  <neroden@gcc.gnu.org>
> >>
> >>        * Makefile.tpl: Make subsituted variables more autoconfy.
> >>        * Makefile.in: Regenerate.
> >>        * configure: Make seds more autoconfy.
> >>
> >>It breaks both the GDB and BINUITLS snapshot processes.  Details to 
> >>follow, however, suggest a short pause.
> >
> >Uh... yuck.
> >
> >Are there some details on the GDB and BINUTILS snapshot processes so that
> >I can fix *them*?  This change is going to happen eventually, even if
> >it's reverted for now; the Makefile changes will be necessary for
> >autoonfiscation.
> >
> >Wait, let me look at Makefile.in...
> >
> >Ewwwww.  The taz rules use Makefile.in *as a Makefile*. 
> >That's the root of the problem, isn't it?  Incidentally, that's
> >disgusting. :-)  
> 
> Well I think ``SHELL = @config_shell@'' is ugly :-)  Why can't the 
> configury code edit ``s/^SHELL =.*/SHELL = $.../''.
If that line is actually the only problem-causing one, I can live without
changing it until autoconfiscation time.  It's the mess of other ones.
:-P

> 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. >:-=

--Nathanael

Re: top level: make more dependencies explicit

[Andrew Cagney]

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

Andrew

Re: top level: make more dependencies explicit

[Nathanael Nerode]

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.

Re: top level: make more dependencies explicit

[Andrew Cagney]

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

``Looks like'' isn't sufficient :-)  The commands:
	gmake -f Makefile.in gdb+dejagnu.tar
	gmake -f Makefile.in insight+dejagnu.tar
and some equivalent for binutils, need to work (I'm not sure what 
BINUTILS uses, ask DanielJ).

You may want to subscribe to gdbadmin (see 
http://sources.redhat.com/gdb/mailing-lists/) so you can monitor GDB's 
snapshot process.

Andrew

Re: top level: make more dependencies explicit

[Zack Weinberg]

On Sun, Sep 29, 2002 at 02:36:24PM -0400, Andrew Cagney wrote:
> What does the GNU coding standard have to say about the release process?

There are some Makefile targets defined for this purpose, but
personally I think that part of the spec is out of date and should be
ignored.

> 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 uses a number of scripts (such as maintainer-scripts/gcc_release)
kept in CVS, but separate from the Makefiles.  I think this is the way
to go.  It prevents exactly this sort of interaction problem.  Also,
the version control policy on release scripts is likely to be
different enough that isolation in separate files will make life
easier.  And it's ever so much easier to write big shell scripts if
you don't have to put backslashes at the end of every line.

zw

Re: top level: make more dependencies explicit

[Tom Tromey]

>>>>> "Andrew" == Andrew Cagney <ac131313@redhat.com> writes:

Andrew> What does the GNU coding standard have to say about the
Andrew> release process?

That `make dist' should make a distribution, and that it should ensure
that non-source files in the distribution (e.g., yacc output, info
files, etc), are up to date.

The standards don't say anything about how this is to be implemented.
It is perfectly reasonable to have the dist target run some random
shell script (that is provided in the distribution).

Tom