[email protected] wrote: > >> or speed_table.c should be compiled separately and linked >> in. >> > > It could be. Would I need to do anything other than add rlink_speed_table.o > to RLINKFILES in src/jtag/Makefile.am, rename rlink/speed_table.c to > rlink_speed_table.c, change static speed_table to extern > rlink_speed_table, and somehow convey how long it is? The latter could, > of course, just be a const int called rlink_speed_table_length or > something like that, since I can't use the sizeof trick to tell how large an > array is if it's defined elsewhere and all the C file using it knows is > that it's an extern pointer. That would, of course, also require the > addition of rlink_speed_table.h, which would be included from both > rlink.c and rlink_speed_table.c, and that leads us well down that > slippery slope of namespace clutter I alluded to earlier. > > It would probably just be a lot easier to rename to .h, than to do this. > How big is the table?
If it is small, generating a .h that is included is fine with me. However, if it gets bigger (and thus requires substantial time for compiling the table alone), then a separate .c file (just as you described - with an additional integer for size, plus a .h with the prototypes) would be better IMHO. > Previously, there wasn't even a speed_table.c. The khz/prescaler table > was directly in rlink.c, and the DTC blobs were loaded from binary files > at runtime. That still had the same issue of how/when to build those > files and added the possibility of mismatch between the version of the > rlink driver and the version of the blob files found on a given system. > While I generally dislike programs embedding blobs in themselves like > that, the cons of having the files separate but in the search path > outweighed the niceness of not embedding. > Hm - the XScale target has the same problem: the debug stub that is downloaded to the target is not compiled-in, but loaded from a binary file. It seems to work fine as long as the dependency is clearly documented. cu Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
