[Freemint-list] FreeMiNT continuous integration

Miro Kropáček miro.kropacek at gmail.com
Thu Apr 13 19:08:24 MSD 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.atariforge.org/pipermail/freemint-list/attachments/20170414/0198556e/attachment.html 


More information about the Freemint-list mailing list