[M3devel] The various hudson tasks

[Jay K]

m3cc is both in its own task and in the cm3 task.
I don't understand why it is in both.
This also causes the sources to be duplicated more.


Given proper incrementality, the split shouldn't be needed. ?
But ok.
Splitting might resemble the future distribution form as well -- ie, one that is more like the old DEC SRC one.
And I'm sure there are incrementality bugs, e.g. like when files are added/deleted/moved.
  Every time I've moved a file it has caused problems.


I kind of think it should always "upgrade" for some definition of that.
Always start with cm3/cm3cg/m3core/config files, and I guess libm3.
Build up to cm3, skipping cm3cg, m3core, libm3.
Copy/install cm3.
Build cm3cg incrementally
Clean everything but cm3cg. Too expensive?
Build m3core up to cm3.
Copy/install cm3.
clean everything but cm3cg. Too expensive?
Build everything.


I can see that might be too expensive though.
On the other hand, if the compiler changes, you really need to buid everything clean.
As I assume incrementality doesn't take into account the compiler's timestamp, and if it did, it'd all be clean anyway.


But I'm not keen on changing this stuff.
It seems kind of difficult and very time consuming to get working, and extremely nice to have in almost any working form.


Thanks,
 - Jay


----------------------------------------
> Date: Wed, 28 Jul 2010 16:49:21 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: The various hudson tasks
>
> Quoting Jay K :
>
> > Olaf, it is a bit odd that there are "m3cc" tasks and "other", but
> > yet "other" does build m3cc.
> > e.g.:
> >
> > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/35/console
> >
> > I seem to always be confused by what the tasks are. :(
>
> There is such a thing as a "standard CM3 system build and if necessary
> upgrade".
> This is included in the (1) cm3-current-build-* jobs for the CVS trunk.
>
> The build of the gcc backend has been extracted from that task, as
> it is based on different and differently licensed sources and takes
> quite a long time compared to M3 builds.
>
> The gcc backend builds are contained in the (2) cm3-current-m3cc-* jobs.
> The result of this job is used by other build jobs if available.
>
> There are two classes of test jobs:
>
> (3) cm3-current-test-m3tests-* just runs the m3tests package tests
> for the compiler.
>
> (4) cm3-current-test-all-pkgs-* is like a "build world"; i.e. it
> compiles all packages, compiles all associated test packages,
> and runs all associated tests if available.
>
> Apart from those there are groups of jobs for building distribution
> archives and for downloading and testing those.
>
> Any suggestions for a better setup are welcome.
> The existing setup has worked reasonably well in the past though.
>
> If anybody wants to play with the Hudson job and try something new,
> he is welcome if he promises not to bring down the existing Hudson
> tasks and other services. Hudson can be completely controlled via
> the HTTP GUI.
>
> 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
>