duane> Either (A) - is done via a cascade of #include files - effectively what duane> we have today, #include <STAR.dot.STAR>, and is shown below via "arm11.c"
zach> That simply is not true. I spent a lot of time cleaning up things, and zach> the tree of headers that you show below is a _gross_ improvement zach> on what was going on before. I can improve this mess further, and zach> without using a common header like you suggest. But we have a "common header file" now, 'types.h' zach> I think that tree is beautiful compared to what it used to be. I agree, what you have done is *FAR* better, all that I am saying is put 'struct target_s;' (and others) in the file "types.h" And it will be even better! ====== I believe that as we go forward, and clean up things - the boiler plate list code will just grow. 3 instances of "image_s" ./src/flash/flash.h:32:struct image_s; ./src/server/gdb_server.h:31:struct image_s; ./src/target/etm.h:30:struct image_s; 2 instances of "scan_field_s" ./src/helper/binarybuffer.h:86:struct scan_field_s; ./src/jtag/jtag.h:261:struct scan_field_s; 6 instances of "target_s" ./src/target/arm_simulator.h:25:struct target_s; ./src/target/breakpoints.h:25:struct target_s; ./src/target/mips_m4k.h:28:struct target_s; ./src/target/register.h:28:struct target_s; ./src/target/target_type.h:6:struct target_s; ./src/target/trace.h:25:struct target_s; 3 instances of ./src/target/armv4_5_cache.h:25:struct command_context_s; ./src/target/target.h:35:struct command_context_s; ./src/target/trace.h:26:struct command_context_s; ====== -Duane. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
