[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