Good structure for a RISC OS GitHub project?
Steffen Huber (91) 1945 posts |
Hi, I am currently looking into ways to structure a RISC OS C project to be published and maintained on GitHub (and/or somewhere else, it doesn’t really matter). I looked into a few other RISC OS projects (PrivateEye, Virtualise, Zap, tbx…) and am not yet convinced about the best way (if there is such a thing). The aim would be to have a ready-to-unzip structure that builds out-of-the-box on any RISC OS machine with a suitable compiler/build tools installed. Same for “use Git on another OS and clone to network share”. Same for HostFS for RPCEmu and VRPC. To avoid losing the file types, I guess all non-text files need a ,xxx suffix, which leads to the question if there is a ZIP/UNZIP implementation that transparently handles ,xxx notation on RISC OS. Should the sources be better in c.blabla/h.blabla format or blabla.c/blabla.h? Can Norcroft handle both ways? ISTR GCC can. Seperating the skeleton !App from the source seems to be a good idea, too. Where to put he build stuff like the makefile? Obviously, there is no working Git client at the moment for RISC OS, but I would expect that it would support filetype name suffixes. How do the current CVS and SVN clients handle this? Has anyone already decided what a good structure is? |
Colin (478) 2433 posts |
CVS adds ,xxx when importing – except for text files – and removes it when exporting. Adding individual files requires the ,xxx to be added explicitly. Files in the repository ending in ,xxx are refered to with the ,xxx added |
Jeffrey Lee (213) 6046 posts |
Ready-to-unzip as in “I can use the github download link”? That’ll be tough due to the filetype issue. Network filesystems are easier to deal with, since they typically support mimemapping for DOS extensions + the ,xxx fallback.
GCCSDK builds a copy of zip that support converting ,xxx extensions to RISC OS metadata when creating zip files. But I think that patch is only enabled for non-RISC OS builds of zip (after all, native files should have the right metadata), and I’m not sure if it copes with the inverse scenario of extracting a zipfile full of ,xxx extensions. However, ROOL’s UnTarBZ2 contains support for applying filetypes from ,xxx and DOS extensions (built into the untar tool), so if you can configure github to offer .tar.gz or .tar.bz2 downloads instead of zip then that should work.
GCC can handle both ways, but it’s probably happier with them in RISC OS form. Not sure about Norcroft – I suspect it only supports the RISC OS way. One tool which might help is srcrename. It’ll convert between Unix and RISC OS folder structures, and could fairly easily be extended to also apply ,xxx filetype suffixes. (If you’re happy with your “builds out-of-the-box” sources requiring a manual step before building – although I guess that step could be baked into the makefile)
I’m fairly certain they all support mimemapping and ,xxx suffixes for mapping filetypes. Not sure whether they handle translating sources between RISC OS and Unix directory structures – it’s been a long time since I’ve used those tools on RISC OS. |
Tristan M. (2946) 1036 posts |
some of the gcc toolchain can’t hold its spaghetti when it comes to RISC OS file / directory handling. It can take some experimentation with a small makefile based project to figure out what works and what doesn’t. |
Chris Mahoney (1684) 2100 posts |
SVN will add .c and .h extensions to files when committing, and will separate them back out into c and h directories on checkout. Other file types depend on the server; I was originally running VisualSVN Server 2 (on Windows) and ended up with ,xxx files in the respository, but I’ve subsequently upgraded to VSVN 3 and the file types are now stored as metadata (and therefore come out as “plain” files if I do a checkout on my Mac). I’m not sure whether there’s a setting to change this behaviour as I don’t need to access sprites etc. on my Mac. |