Clang format

[mheyer32]

I'd like to contribute more in the future but having trouble merging your changes back into my fork, often time introduced by whitespace differences. To make merging less painful, I'd like to introduce a common clang-format file that we can both agree on.

Please let me know if you are open to the idea of taking PR's from me. If you don't like the clang-format style that I selected, please suggest enhancements. clang-format is quite malleable. I tried to find a style that fits the files you're mostly working on. Currently there's multiple different styles for bracing, line break etc in the project, so some other less worked on files need more changes.

Thanks for your time!

[rkujawa]

I'd say the main issue here is not the format, but the fact that development takes place on a classic AmigaOS which does not have proper git implementation. So this repository is, in fact, a mirror of a CVS repository. Therefore, contribution via GitHub PR is not viable. Assuming, @DvdBoon is interested in taking contributions, another workflow would have to be established (there are a few options, ranging from good 'ol unified diff via email, to granting access to the CVS server).

[mheyer32]

Can we somehow make it so that the GitHub repo becomes the central ground truth? How does @DvdBoon currently move code between GitHub and that CVS repo?

[rkujawa]

@mheyer32 There are a couple of problems here:

• As mentioned, development takes place on a classic AmigaOS, using native tools, while there is no working git client. So there is no way for @DvdBoon to directly interact with GitHub. GitHub only works with git protocol.
• Currently, @DvdBoon commits everything from AmigaOS using CVS client, to a private CVS repository on a server that I run.
• On the mentioned server, there's a script running every circa 15 minutes, which uses git cvsimport to synchronize commits from CVS modules into git repositories (there's many of them, in fact most of Amiga-related repositories in Sakura-IT GitHub org work that way). The script is very dumb and works one way only - i.e. from CVS to GitHub. Implementing anything other than one-way synchronization would be non-trivial - there's no trustworthy method of synchronizing git changesets to CVS. The obvious downside is that no changes can be made to the repositories on GitHub.

So I can only see the following possible methods of solving this:

• Move development to another OS, where git client is available. Seems troublesome, considering the character of driver development, which needs access to real hardware.
• Continue development as-is, but store local copy of repository on another OS, where git client is available. This is certainly possible, but requires complexity on the client side - i.e. @DvdBoon would need to use two different machines just to achieve the same thing as currently... Imagine, that either whole copy of git repository would need to be available to AmigaOS (via Samba or NFS), or at least cross-compiled binaries would have to be synchronized in some way. That just moves complexity from the server side to the client side, at the potential benefit of making GitHub a single source of truth. I'm not willing to spend my time on inventing such kludge... Consider the fact that now @DvdBoon just needs native CVS client and internet access (i.e. running TCP/IP stack) on AmigaOS.
• Someone finally implements git client for AmigaOS 3 and the whole problem solves itself.

Out of curiosity, what is your git workflow for projects that can't be tested easily on emulators?

[mheyer32]

I'm using Bebbo's cross compiler GCC and develop in a Linux VM. My A3000 is network attached. So I develop and build on the PC and use a tool called 'squirt' to push files very quickly and automated to the A3000. Reboot, restart P96 and test... rinse and repeat. Its a very convenient workflow as my development environment is completely unaffected by crashes or reboots on the Amiga side.

[mheyer32]

This is how it looks like for me:

I'm using QtCreator as IDE. It has all the bells and whistles needed nowadays and can be configured to 'understand' Amiga code, so you get all the niceties like syntax highlighting and go-to-definition, clang-format, refactoring tools etc... I do not have the ability to do source debugging with P96, but I'm connected to the machine via serial, so I'm getting to see the KPrintF output in a terminal window. I also run a telnet-like server on the A3000 which allows me to "ssh" into the machine to run console commands remotely.

[rkujawa]

@mheyer32 Thanks! So you've got a setup with complexity on the client side, but it seems that it works well for you. I'm interested in what @DvdBoon thinks and whether he's willing to make changes to his workflow.

[DvdBoon]

The problem regarding formatting for me is that I used 2 different editors on the Amiga. The Devpac editor in the past which uses tabs as tabs and GoldED (from within CubicIDE) that uses spaces as tabs with no highlighting to see which is which.

In the past I have tried to correct it here and there.

GoldED is very configurable, I really should check how to set it up correctly. In the past it didn't matter much as I was the only one working on it anyway.

Let me get back on this.

[mheyer32]

When I started with this patch I thought my problem was the formatting... I didn't realize it went deeper than that. Formatting (in particular whitespace differences) can easily be made to be ignored by various merge tools.

What will be more difficult is keeping the commits in CVS the same way they are in Git and vice versa. When I first approached DvdBoon about some changes I was surprised he just didn't straight away cherry pick my changes via git and instead went to reimplement them in a slightly different way. Now I know why.. because he has no way to take changes from Git and make them appear 1:1 in CVS.

Maybe we can find a way. For instance there is a "Git CVS Server Emulator" https://git-scm.com/docs/git-cvsserver That allows a git server to behave like a CVS server. I.e. you can locally (on the Amiga) use CVS and once the changes are uploaded to the Git server (behaving like a CVS server) we can synchronize/cherry-pick/pull from it to GitHub. This should also work the other way around: make changes that were made in git visible to CVS again