[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