This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Step-By-Step Build Instructions for MinGW gcc/gcj 3.4 Compilers


Quoting Erik Poupaert <erik.poupaert@skynet.be>:

> Also the additional mingw stuff should probably be in variables, so that the
> maintainer can easily upgrade tarball references and things.

My "design" is that the build script is always downloaded before
it is executed, hence the script itself is a variable.

Anything beyond that is welcome as maintainence/hacking convenience.

> Then we still got a few outstanding issues:
> 
> * 3.3 versus 3.4?

Command line arguments per my suggestion in the "Issues" section?

> * downloading from CVS versus release/snapshot

I think the main focus should be stability.

Downloading snapshots might be more stable than doing a cvs get/update.

> * ? need for buildserver + rsync

How about creating a sourceforge project?

That would make it easier to share the responsibility. This discussion
grew from a concern about Mohan being a bottleneck(and him getting enough 
sleep! :-)

We could use CVS to keep scripts/documentation/patches.

The builds would run on the maintainers machines and the result would be
copied to the Sourceforge project. Since a build takes a while, 
the builds could be split between several machines/people.

(Sourceforge is just a convenient technology/site choice. I'm sure there
are good alternatives. GNU Savannah?)

> We should also establish an upgrade policy that balances the need for
> stability with
> the need for having more people on fresher versions. The maintainer could
> then apply
> this policy.

I suggested in my "Issues" section command line arguments to the build script 
to choose between latest, stable, etc.

We could also keep a number of prior versions, ignoring server capacity.

> We should also have a page at the GCJ website where we can explain how this
> simplified procedure works (with fewer install steps). I don't mind taking
> care of
> it, unless someone else wants the job.

Would you be interested in starting out as a Sourceforge project maintainer?

I set up a sourceforge project once(for kicks), it is not hard.

Øyvind



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