Abuse of filenaming and portability

In RISC OS the the user has free rein over where she puts her files and what she calls them, outside of $.!Boot, with the exception of names reserved by the OS like !Boot, !Run, !Help and !Sprite which signal their singularity with a leading pling. By abuse of filenaming I mean anything which breaks this freedom. Sadly the Toolbox does this by insisting on the name Res for ResourceFiles. My own stick program does too by insisting on !Drag, Select and !Adjust but I plead mitigation in view of the leading plings. An application should never hardwire filenames into its code. It should use system variables instead, initializing them to particular filenames in !Run (or some Obey file called before the application is started) and then using those in its code. There are lots of hygienic reasons for this, which I won’t deviate into here. My reason for bringing this up is that Unix has no qualms about abusing filenames. In the absence of separate filetypes, Unix applications, and in particular C compilers and Make filename extenders play a huge role. RISC OS has willy nilly followed suit, but with an extra twist of confusion. Where Unix expects C source code to be in a file named foo.c and headers in foo.h, RISC OS might reasonably expect to see foo/c and foo/h. But somebody decided that was too simple-minded and that c.foo and h.foo would do instead. So how should host/buildvm.c get
translated? As host.c.buildvm or host.buildvm/c? Translating between Unix and RISC OS makefiles is now a confusing mess.

I am trying to port LuaJIT 2.5.2 to RISC OS and the above-mentioned mess is doing my head in. I believe this to be a feasible, even useful project. LuaJIT is blindingly fast and would be a convenient tool. But I fear that there is nothing for it but actually to understand what the makefile is saying and then to do swathes of renaming so that the port of GNU make to RISC OS can do its stuff in this project.

I would prefer it all just to work, so that I can let the understanding part go hang. Lee Noar has been very kind and given good advice. More help needed, people! There is a ripe juicy pay-off hanging on a low-branch, that is yet too high for my confused brain. Come and get it.

Sadly the Toolbox does this by insisting on the name Res for ResourceFiles.

Isn’t toolbox the one that uses numbers for internationalised things?

But somebody decided that was too simple-minded and that c.foo and h.foo would do instead.

It’s “tidier”. All the c files together, all the header files together, and all the assembler files together.
I’ve been using an old DOS compiler for something, though this applies to newer ones too, and I find the mess is infuriating. Everything is all shoved in together. The source, the headers, the object files. It’s basically vomiting up every stage of application development in a bowl and thinking that’s a good idea.
No, I’m with whoever in Acorn decided to make the ‘extension’ become a subdirectory. Much MUCH easier to work with.

So how should host/buildvm.c get translated? As host.c.buildvm or host.buildvm/c?

In RISC OS terms, it ought to be host.c.buildvm.

and the above-mentioned mess is doing my head in

Sounds like what you need is a little Lua program to take the various source files, strip the extension, and put them in the correct subdirectories.

but actually to understand what the makefile is saying

I’m not sure what happens if subdirectories are specified, like host/something.c but I believe that Make/AMU convert references to “this.c” to be “@.c.this”.
Does the C/C++ manual topic on filename conventions (it’s early, try around page 25) help?

yet too high for my confused brain

I cannot help more with MakeFiles. They’re a certain sort of magical incantation.

I got a MakeFile working nicely once. So now I just copy that and change the names of thing as appropriate. Simpler than actually figuring out MakeFile syntax.

GCC seems to be “all or nothing” so if you want to use foo/c and foo/h EVERYTHING has to be that form, including the libraries.

I have a similar mess trying to get python to compile C code into extensions.

@ Gavin (and others)

for GCC have you tried to define a path variable? For example:

Set MyLib$Path <Obey$Dir>.

And then pass it to GCC via -I option as follow:

gcc blah blah -IMyLib:

Then in the c source you can use:

#include <mylib.h>

And finally for ld linker you can use:

For static libraries:

gcc blah blah -l:MyLib:mylib/a

No, I’m with whoever in Acorn decided to make the ‘extension’ become a subdirectory. Much MUCH easier to work with.

With a 77 files/dir limit (or even 47 for the older formats), did they have much choice?

I’ve been using an old DOS compiler for something, though this applies to newer ones too, and I find the mess is infuriating. Everything is all shoved in together. The source, the headers, the object files. It’s basically vomiting up every stage of application development in a bowl and thinking that’s a good idea.

Maybe DOS, but that’s not universal.

GCC, in the SDK guise at least, is quite happy to have different folders for different things. All of my .c and .h files live in src/, for example, while .d and .o end up in obj/. This means that make clean just has to do

rm -r obj/*

to remove all of the compiler’s intermediate junk while leaving the files in src/ alone.

With a 77 files/dir limit (or even 47 for the older formats), did they have much choice?

No.

I also wonder if c.foo / h.foo has some history in the MOS and DFS, where that was about the only way you could do it.

Exactly that, Chris.