[Freemint-list] FreeMiNT continuous integration

[OL]

Ouaouh!


Very very nice tool, we even not dream it, but you do it ;-)

Thanks a lot.

Olivier
> Hi all,
>
> it saddens me to announce this three months after my initial work on 
> github and travis transition but it's been fi-na-lly done. What? 
> Everything you could ever ask for in the FreeMiNT project. ;-) OK, 
> perhaps not everything but coming pretty close to it:
>
>   * Automatic publishing on https://freemint.github.io/#snapshots
>     after each new commit for *freemint*, *mintlib*, {cf,gem}*lib*,
>     *fdlibm*, *mintbin* and *qed*
>   * All regular builds have history, so you can browse in previous
>     builds, useful when looking for working version of something
>   * Every pull request gets own separate build to test, the build url
>     is automatically linked in the PR's comments section
>   * Super convenient FreeMiNT and Qed builds (you'll get everything in
>     one package, more on FreeMiNT this later)
>
> Some technical information can be found here: 
> https://github.com/freemint/freemint/wiki/FreeMiNT-builds-and-continuous-integration-explained
>
> So, now let's talk about FreeMiNT. My main goal was pretty simple and 
> yet as complex as it gets: ridiculously easy testing so everyone, 
> simply everyone, can grab a build and give it a go. No waiting until 
> midnight, no compiling, no setting up /anything/, no messing up with 
> kernel modules, no overwriting existing (working) configuration. 
> Another goal was to have everything in its as default as possible 
> settings so all bugs would be immediately visible, not hidden thanks 
> to some "clever checkbox".
>
> So how did I do that:
>
>   * got rid of the vague "-cur" suffix and replaced it with first
>     three digits of git revision so you're going to get unique $SYSDIR
>     for each build you'd like to test (ok, in theory there could be a
>     conflict but I don't expect that anyone would have 100 1-19-xxx
>     folders in C:\mint)
>   * utilised mintloader.prg to the max -- so not only $SYSDIR but your
>     AUTO too would always contain unique MINT-xxx.PRG
>   * utilised my ancient (and seemingly useless) patch for MCHDIR --
>     now the builds aren't divided by CPU but by /machine/, i.e. when
>     you run MINT-xxx.PRG, you can be pretty sure no "foreign" kernel
>     modules are going to load
>   * no more hassle with "what binary/module I need for my machine" --
>     there are only three (very easily recognisable) archives: basic ST
>     (000), all the others (020+) and the FireBee (col), thanks to the
>     machine folders you don't have to do anything else, you can use
>     the same snapshot on the Falcon, CT60 and Aranym (!)
>   * this all means one thing: grab a snapshot, unzip it on C:\, rename
>     your working MINT*.PRG in AUTO to MINT*.PRX and reboot. That's it.
>     No other setup needed (even NVDI.PRG will be before the new
>     MINT-xxx.PRG) except setting your favourite desktop in XAAES.CNF;
>     when done with testing, simply delete C:\AUTO\MINT-xxx.PRG and
>     C:\MINT\1-19-xxx
>   * to make this even easier, there's an Aranym build available, yes,
>     dynamically generated standalone Aranym image with desktop, fvdi
>     and emutos after each commit! So now really /anyone/ can test new
>     kernels
>   * you'll get complete FreeMiNT distribution (sans the dev docs, this
>     needs to be sorted out first, see
>     https://github.com/freemint/freemint/issues/2), i.e. all the
>     READMEs, tools, additional files /for all three platforms/
>   * since we couldn't come to an agreement with Alan, the previous
>     old-fashioned build (everything in one archive) is still available
>     -- I didn't touch it and don't plan to; also Alan's usb4tos
>     archive is available at the same place
>
> That's more or less everything I can think of. It took me a lot of 
> time to figure it out, in the end it all kind of makes sense but there 
> were times when I was ready to give up, esp. the PRs had given me 
> headache for at least three weeks.
>
> Of course, there's plenty of things to improve:
>
>   * detect Hatari and MegaST machines (right now minthat.prg is never
>     executed and "megast" mchdir is never used)
>   * finally unify the build process (so I can type make CPU="xxx" and
>     get the /complete/ binary output, right now it's "patched" for
>     specific folders -- mainly *loaders and tools)
>   * some tools need STG compiled to HYP, thanks to Thorsten's tool
>     it's possible but I simply can't find energy to do this
>   * extend the freemint builds with bash, qed, maybe some other tools
>     (core-utils?)
>   * use latest libs when building apps (qed, mint tools, ...), i.e.
>     the script would download and depack latest binary snapshot before
>     building instead of relying on Vincent's packaging
>   * generate qed for all three platforms (I reverted the build back to
>     68000 for now)
>   * more exotic things -- setting up Travis with Aranym so one could
>     compile any package natively using freemint's gcc by simply
>     forking travis-scripts and adding build.sh, ideal for ./configure
>     based tools; setting up vnc on freemint and run (!) the aranym
>     image there (actually, I have done this as a proof of concept,
>     just with sharing aranym's screen -- it was too slow, we need a
>     bridged connection directly to freemint)
>
> That's pretty much it. It has been an interesting exercise (albeit a 
> bit time consuming), definitely applicable outside FreeMiNT/Atari 
> world. If you would like to see something similar in your Atari 
> project (EmuTOS, wink wink ;)), feel free to fork "travis-scripts" and 
> start from there, I'll happily give you a hint or two.
>
> -- 
> MiKRO / Mystic Bytes
> http://mikro.atari.org
>
>
> _______________________________________________
> Freemint-list mailing list
> Freemint-list at mail.atariforge.org
> http://mail.atariforge.org/mailman/listinfo/freemint-list


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.atariforge.org/pipermail/freemint-list/attachments/20170413/4b01c798/attachment-0001.html