public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: top level: make more dependencies explicit
       [not found]     ` <3D973C44.6090601@redhat.com>
@ 2002-09-29 11:33       ` Nathanael Nerode
  2002-09-29 12:07         ` Andrew Cagney
  0 siblings, 1 reply; 4+ messages in thread
From: Nathanael Nerode @ 2002-09-29 11:33 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: gdb, binutils, gcc

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: top level: make more dependencies explicit
  2002-09-29 11:33       ` top level: make more dependencies explicit Nathanael Nerode
@ 2002-09-29 12:07         ` Andrew Cagney
  2002-09-29 13:01           ` Zack Weinberg
  2002-09-29 16:34           ` Tom Tromey
  0 siblings, 2 replies; 4+ messages in thread
From: Andrew Cagney @ 2002-09-29 12:07 UTC (permalink / raw)
  To: Nathanael Nerode; +Cc: gdb, binutils, gcc


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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: top level: make more dependencies explicit
  2002-09-29 12:07         ` Andrew Cagney
@ 2002-09-29 13:01           ` Zack Weinberg
  2002-09-29 16:34           ` Tom Tromey
  1 sibling, 0 replies; 4+ messages in thread
From: Zack Weinberg @ 2002-09-29 13:01 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: Nathanael Nerode, gdb, binutils, gcc

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: top level: make more dependencies explicit
  2002-09-29 12:07         ` Andrew Cagney
  2002-09-29 13:01           ` Zack Weinberg
@ 2002-09-29 16:34           ` Tom Tromey
  1 sibling, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2002-09-29 16:34 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: gdb, binutils, gcc

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2002-09-29 22:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20020929165232.GA27545@doctormoo.dyndns.org>
     [not found] ` <3D9733C2.2010405@redhat.com>
     [not found]   ` <20020929172608.GA27678@doctormoo.dyndns.org>
     [not found]     ` <3D973C44.6090601@redhat.com>
2002-09-29 11:33       ` top level: make more dependencies explicit Nathanael Nerode
2002-09-29 12:07         ` Andrew Cagney
2002-09-29 13:01           ` Zack Weinberg
2002-09-29 16:34           ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).