Originally Posted by wXR
Wow that's pretty neat. Can you share the setup for that workflow somewhere?
It's no magic actually, just careful planning.
From my experience, if you want to develop something in an open source way, you need to make the whole workflow as painless as possible. If your environment is complicated for the developer, it will result in rare code releases (think decelerator4030 :P). If you need to do some special things just to get the code out, it's a waste of time that could be spent on actual development.
With Sonnet project we wanted be able to build it on both AmigaOS and UNIX-likes. We also wanted to do proper code versioning _and_ to be able to share it publicly, just in time, as it is developed.
This required selection of appropriate tools, to make it as automated and convenient as possible. First, linker, assembler and so on (sonnet.library is mostly written in assembly). The only actively developed suite, that works both natively and for cross-compilation is vasm/vlink/etc. tools by phx. The alternative would be GNU as, ld, etc. but they aren't getting much Amiga love recently and are just huge. Also, phx being an Amigan, happily added more features as we requested them
Other requirements are minor, like GNU make to build the whole project and the required include files that sonnet.library is depending on (AmigaOS NDK and WarpOS includes).
When it comes to code versioning workflow looks like this:
- Let's say on Amiga I am developing the code, I write, write, write
- Once I am satisfied with the result I do "cvs commit", which sends the updated code to CVS repository on the UNIX server (there is a nice Amiga port of cvs client done by phx), naturally this requires the Amiga to be connected to the internet.
And that's it! Couldn't possibly be simpler.
The rest is done automatically:
- There's a cron job on the CVS server that checks for new commits every 15 minutes.
- If there is a new commit, it runs a script that calls "git cvsimport", which updates the local git-converted repository with latest CVS changes.
- Then the changes are pushed to GitHub with "git push".
Additionally we have a script running on the CVS server that checks for commits and tries to do automated build of the whole project. So we can almost immediately see, if the commit resulted in some regression. The build results are shared via web
then. In a modern open source projects this is called "continuous integration" and is nothing unusual really.
The actual build procedure for sonnet.library is laid out in TOOLCHAIN
Note the focus on simplicity for the developer. It works so well only because it is painless. If I had to manually move the code to PC just to commit it, I just wouldn't do it - I am too lazy.