[M3devel] additional CVS repositories for additional gcc forks?

[Jay K]

 > No. I would see a C backend as a variant (option) too, but probably not
 > use it on platforms were I can compile without it.
 

I would like to see a C backend at least replace the gcc backend.
   We could maybe then slowly iterate on the integrated backend. Or LLVM.
It would provide more obvious correctness, better debugging, better code quality.
Imagine -- basically all platforms would get stack walkers.
  By generating C++ for most platforms, or using C exception handling in NT/VMS/Tru64.
Basically all platforms would just work.
Stock debuggers would work, gdb and others.
Basically no more porting.
Basically all optimizations could be enabled.
  (Aside: I think the generated C would be sure to store
  gc roots in volatile locals, but not otherwise use said volatiles.)
And in more recent developments, it would enregister some records passed by value.
It would, in a sense, shrink the code base (cheating sort of).



I'm not holding my breath on any of this.
But I'm going to start trying to do more and talk less about it.


 - Jay

----------------------------------------
> Date: Thu, 26 Aug 2010 12:59:16 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: additional CVS repositories for additional gcc forks?
>
> Quoting Jay K :
>
> > Olaf, I have some temporary so far hypothetical interest in trying
> > gcc 4.3.0 again -- the SOLgnu/SOLsun problem with 4.3.5.
> >   Really, hopefully that's not something needed long term.
> >
> > I have some possibly lasting so far hypothetical interest in another
> > gcc fork -- to fork OpenBSD's 4.2.1.
> >  Though I guess I can try to apply their patches to 4.5.1.
> >
> > It is trivial and reasonable?
> > Or it would be a pain in Hudson?
>
> The main problem wrt. performance and i/o load is importing different
> gcc versions in different directories and not as different versions.
> Thus they get stored as lots of new different files, which all need
> to be read and their directories locked. The gcc structure is huge
> compared to all the M3 code. Of course, if we use the gcc versions in
> parallel, i.e. they are variants in one of our configuration, this
> is actually needed.
>
> It might help if you postpone your gcc projects for some weeks until
> we've either moved our WWW services or setup a repository mirror or
> whatever.
>
> >   In paritcular the notion of gcc-openbsd in a separate repository?
> >   I actually think maybe we should use gcc-apple for *_DARWIN but
> > Tony disagreed and mainline seems ok.
> >   It is for ARM_DARWIN, which isn't in great shape (Hudson?! :) )
> >
> > I'm open to moving the existing gcc (gcc-4.3/gcc-4.3.5) to its own
> > repository.
> > And the existing gcc-apple to its own.
>
> I wouldn't like to change much now, just remove what we really don't
> need.
>
> > (Besides, a C backends wipes this all away. : ) )
>
> No. I would see a C backend as a variant (option) too, but probably not
> use it on platforms were I can compile without it.
>
> > I don't much like CVS but I have slowly learned to use it a bit.
> >   My favorite by far by far is Perforce. We could possibly use it
> > free for open source work.
>
> Perforce is nice, agreed. I haven't used it much in practice though.
> I'm not sure how much effort it would cost us to get a Perforce setup,
> and if all users would be comfortable with it.
>
> > I have lots of experience with it. It is fast. It has good gui. It
> > has atomic changes. It does branching right (unlike svn which does
> > branching completely wrong)
>
> I wouldn't say that, though subversion still has several severe problems
> with merging, especially tree merges.
>
> > I have no experience with anything else -- svn, mtn, git, hg, etc.
> We (Elego) have, but the experience of the M3 developers will vary
> very much I think.
>
> Git may be an interesting option, though I'm not sure if it is really
> mature enough and has got all the infrastructure support we may need.
> We've got commercial customers who are thinking about switching over to
> it completely though.
>
> As I've said before, switching to another version control system will
> involve much tedious work, and I cannot contribute much (time)
> for that. However, if the M3 community decides to use something
> different and plans and implements a reasonable migration to the
> new tool(s), I wouldn't object to that.
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>