Kernal source organisation

The subdirectories in the .s directory for the kernel have been a pet peeve of mine. As far as I have seen it’s the only part of RO that has that structure. It also causes some issues when using svn and sgit.

I just did a quick reorganisation of the BCM kernel source and uploaded it using sgit. So, unfortunately that will mean that some file type setting will need to be done when re-downloaded.
The kernel I uploaded builds successfully.

TBQH I’m still not 100% happy with where I plopped the source, but at least now it is parsed correctly as directories containing .s files.

See the link below.

e: Dropbox link to zip of kernel tree made with infozip. This will have the correct, un-parsed structure.

https://gitlab.com/risc_os_strays/kernel_reorganised

https://www.dropbox.com/s/xdu2mp48g9vc1hp/Kernel.zip?dl=0

e: I guess CBM left a lasting impression on me. Can’t edit the title.

TBQH I’m still not 100% happy with where I plopped the source, but at least now it is parsed correctly as directories containing .s files.

Which is not standard practise under RISC OS and contradicts GetAll.s which requires directories named “s” containing files.

What are sgit and svn doing wrong?

What? … oh. An omission on my part. It needs to be downloaded to a RISC OS machine first. Then it will have the file structure I set up.
I don’t really know of the resources to let me put an RO tree somewhere as is.

 


sgit clone <a href="https://gitlab.com/risc_os_strays/kernel_reorganised.git">https://gitlab.com/risc_os_strays/kernel_reorganised.git</a>

When it is the latter there can be parsing issues because s is both a path and a filename.

Sorry. I’m out of time. Hopefully that explanation is at least decipherable.

The forum is being stupid. The url doesn’t look like that when I edit.

I have a zip of the kernel sitting, waiting to be uploaded somewhere. Suggestions?

e: I made a zip of the Kernel source in RO and put it in the top post.

It’s hard to explain but there can be a collision between s.files and the s directory with subdirectories of files. It kind of results in a hard to weed out anomaly which can prevent downloading the tree.
The only way I’ve found to fix it is to correct it on a POSIX platform, push (or whatever) that, and then remove and re download the offending part of the downloaded repository.

It’s hard to explain but there can be a collision between s.files and the s directory with subdirectories of files.

It is likely that the GCCSDK sfixing routines that sgit is built with are not handling the sub directories.
I cant ever recall seeing c/someotherdir/actual_c_file being used and it might be tripping it up.
You could try experimenting with gcc, it /might/ unsuffix this where the norcroft wont.

https://www.riscosopen.org/forum/forums/11/topics/12657?page=1
Jeffrey came to my rescue on this in a sense. I was oblivious to being able to configure UnixLib handling of suffixes.

I still do find those subdirectories of ‘s’ in the kernel kind of strange. It’s why I rearranged them (see the zip) to a more conventional format.
I’m proobably the only person on the planet that’s bothered by their arrangement, but I have not seen it anywhere else.