RESFSDIR handling in CModule
Jeffrey Lee (213) 6048 posts |
A couple of components (DrawFile, TinyStubs) weren’t producing functional ROM builds because their resources weren’t being exported. After a bit of investigating I discovered that both the CModule and AAsmModule makefile fragments use RESFSDIR to specify the location the resources should be copied to. AAsmModule will give RESFSDIR a default of ${RESDIR}.${COMPONENT}, but CModule doesn’t give any default – i.e. if the two components were assembler modules everything would have been fine, but because they were C modules they required fixing by manually specifying RESFSDIR. At the moment I’ve fixed this in CVS by explicitly specifying RESFSDIR in the makefiles, but I’m thinking a more sensible thing to do would be to update the CModule fragment so that it generates a default RESFSDIR value in the same way as AAsmModule. Thoughts? |
John-Mark Bell (94) 36 posts |
It seems sensible to ensure that the behaviour is the same regardless of whether the component makes use of C or not. |
Ben Avison (25) 445 posts |
Mea culpa – I rewrote those makefiles to permit soft-loadable versions to be built, and obviously didn’t test the ROM build… I agree that CModule should use the same default RESFSDIR rule as AAsmModule. The general idea of the shared makefiles is to minimise the size of each component’s makefile, and sensible default rules are very useful for that. It’s certainly very common for a module to use a subdirectory of Resources:$.Resources which shares the component’s name, whether it’s written in assembler or C. |