Ticket #150 (Invalid)Mon Sep 17 21:35:40 UTC 2007
Failure to compile PRISMLib
| Reported by: | Rob F Johnson (156) | Severity: | Normal |
| Part: | Legacy: Batch 1 issues | Release: | |
| Milestone: | Status | Invalid |
Details by Rob F Johnson (156):
I had a problem building PRISMLib in BatchOne. 3 of the C sources (JobQueue, NRArrays, RLIsts) wouldn’t compile because of missing headers. I tracked it down to 1 header (FuncTypes) included by 3 headers (Internal, NRArrays, RLIsts). The header wasn’t actually missing, but couldn’t be found by the way it was called.
The ‘missing’ header belongs to PRISMLib itself, and is present in Sources.Lib.PRISMLib.h. It is #included as “PRISMLib/FuncTypes.h”. Unfortunately this won’t track to the local h directory.
The #include is in this format because the (only so far released) component (Video.Render.ScreenFX) that uses PRISMLib finds it as a subdirectory of Export.APCS-32.Lib, which is on the default C: path. PRISMLib doesn’t have a path of its own.
Because Export.APCS-32.Lib is on the default path, the PRISMLib headers there are automatically made available to compilations of PRISMLib sources. But on the first run through, there is no PRISMLib in Export.APCS-32.Lib.
Once PRISMLib has been released to Export.APCS-32.Lib, the compilations will stop failing. But the problem hasn’t actually gone away. If FuncTypes.h is amended in the original Sources copy, the changes won’t be picked up by recompilations of PRISMLib.
There are 2 solutions to this I can see. One long, the other quick.
The long solution is to bring PRISMLib into line with ConfigLib and zlib. When their headers call each other they just say “xxxx.h” and so in compilations of their own sources they automatically find headers in the local h directory. Other components that call ConfigLib or zlib headers also just say “xxxx.h”. These other components find the released headers by quoting e.g. -I C:zlib in their compilation parameters. The solution would involve removing ‘PRISMLib’ from all header calls, both in PRISMLib’s headers and in the sources of other components. And putting -I C:PRISMLib in the other component’s Makefiles.
The quick solution is just to change PRIXMLib’s Makefile, by adding the line CINCLUDES = -I^.,C:. This makes Sources.Lib get searched before the standard libraries. I have appended an amended copy of the Makefile.
Changelog:
Modified by Rob F Johnson (156) Mon, September 17 2007 - 21:37:00 GMT
- Attachment added: Makefile
Modified by Andrew Hodgkinson (6) Tue, September 18 2007 - 23:12:18 GMT
I think the whole thing here just boils down to you needing to run !MkExport before you try to build an individual component. The need isn’t obvious until, as Ben put it in an e-mail to me recently, “you’re compiling
a large number of components with circular dependencies (such as a ROM
build)”.
The general rule is to always run the export phase before trying to build any individual component. If you were to update exported headers as part of code changes, then of course you would need to run the export phase again.
If this solves your problem then please close the ticket, else feel free to describe any remaining issues and we’ll see if we can help resolve them.
Modified by Steve Revill (20) Tue, October 02 2007 - 17:38:42 GMT
- Status changed from Open to Invalid
Closed.
