This is the mail archive of the gcc@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: Analysis of remaining EGCS references 2


On Sun, 12 Nov 2000, Gerald Pfeifer wrote:

> On Sat, 11 Nov 2000, Joseph S. Myers wrote:
> > ./contrib/release:mv egcs $release_name
> >
> > This is a regression from last time (a testcase is needed :-)).
>
> The reason why we added this script to the GCC tree is exactly so that
> everyone can help improving it. And in fact, the first patch already
> arrived today. Further patches welcome! :-)

As a first step, I think we need all relevant programs it uses to be in
CVS -

update_changelogs
release_docs

and for the snapshot script

update_links
update_tags

and the applicable crontabs.

Then, a few questions:

* Would the snapshot and release scripts better be a single script (or
share some parts)?

* Should the details of what goes in each part (gcc-core, etc.) of a
distribution go in the modules file - at present somewhat out of date -
instead of the scripts?

* The release script excludes certain files (de.gmo, fr.gmo) from diffs -
is this for texinfo, and wouldn't diff -a be better?

* What's the logic of the division into components of the testsuite?  I'd
have thought that either each language (including objc) should have its
own tarball for its bit of the testsuite, plus a testsuite core one with C
and lib files, or else the testsuite should be distributed as a whole?
(Is it supposed to be the case that the component files gcc-core etc. for
a GCC distribution contain disjoint sets of files, whose union is the set
of all files in the full GCC distribution?)

* Is the logic to ensure that generated file diffs get included after the
diffs to the source file hidden there somewhere, or missing?

* There's probably more, but notwithstanding that the existing scripts
work at least as long as you get a tarball for the whole distribution and
diffs for the whole distribution and are willing to get a new tarball in
the event of patching problems, some bits of the scripts are enough of a
mess that it isn't clear what the specification or design principles for
them are.

-- 
Joseph S. Myers
jsm28@cam.ac.uk


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