[M3devel] Hudson structure?

Jay K jay.krell at cornell.edu
Wed Nov 10 10:08:53 CET 2010


 > I seem to remember that there were objections to _not_ ship cm3cg to bin though

I think it actually ship to bin/target or bin/host/target, but that
is a different matter.


Anyway, the problem is solved, in that upgrade.sh doesn't ship m3cc.
As long as we use upgrade.sh and don't just launch into a buildship of
everything, ok.


 > stuff running in parallel
 
  ah
  

 > The m3cc builds takes hours on some systems
 
 
They should be faster now and better at being incremental.
  (somewhat contradictory: I used to throw -disable-dependency-checking
  as a speed up, now I don't; Cygwin is probably significantly slower
  therefore, far more forks(), but other platforms not)
 
 
But that doesn't completely counter your point.
  gmp/mpfr/mpc were a significant portion, almost gone now
    (I'm tempted to further reduce them -- one of the main
    existing dependencies is in loop unrolling, but
    the frontend I think already does loop unrolling;
    but cm3cg should be able to do better since it does
    more sophisticated analysis -- and still, cm3cg
    has available efficient 64bit integers without gmp,
    the need for gmp is in general therefore, unclear;
    the need for mpfr is actually sort of "more clear", except
    that it isn't used where I thought it might be -- it isn't
    used for floating point constant propagation, but for implementing 
    builtin" functions; besides, floating point is essentially
    identical across all build hosts, so doesn't need to be "simulated";
    and mpc is for complex math, which we never use..mpfr
    and mpc are completely gone, gmp is much smaller than previously)


I'm torn now.
I want to test an m3cg.i3 change, but if it fails, I don't want to do the tedious recovery.
Maybe if I'm quick, only one or two machines will see it?

 - Jay 		 	   		  


More information about the M3devel mailing list