Hi David, At the begining let me thank you for seriously addressing my concern. I aggre that approach with global list of includes is not perfect. But it's been in use for so long by so many people in my company that switching to something else at this point is simply impossible. They are using Tasking compiler which comes integrated with some derivative form of Eclipse IDE. What I have to work with is preconfigured, There is a lot of auto generated code and changing the approach would require extrem amount of work which I simply cant handle on my own. I didnt invented it. I'm just trying to make it work in my Software in the loop solution for testing purpouses and not having a compiler that could handle this amount of load is a big no no for me. I will simply switch to Clang and never think about this problem again.Thank you all for you valuable sugestions. Kind Regards, Filip This all sounds like a very questionable way to organise your project. > (I hesitate to say "wrong", because people have good reasons for > organising projects in different ways, and sometimes it's just down to > personal preferences. But if I were given charge of this project as you > describe it, I'd say it's wrong and must be changed.) > > I would say that if you are listing a large number of include > directories in the include search path, you are doing things wrong. > This is especially true when you have code from different places and > different modules - you are just asking for trouble when there are > filename clashes between parts. It is much better to put the directory > explicitly in the #include statements. Alternatively, you can have > indirect inclusions - have a single directory "modules_includes" that > has an include file for each module. Those include files have nothing > but an include directive with the real module public include file, > including the directory. This "modules_include" might then go on your > compiler include path, but I'd not do that either. > > That way you can easily include the files you want, and not accidentally > include private headers that are internal to modules. It is much easier > to find what you want, and much easier to read the source code. When > you see "#include "modules_include/foo.h" ", or "foo/public.h" > (depending on which solution you use) in the source code, you know it is > the public interface for the module "foo". You don't have to wonder > which of the hundred directories it might be in or what module it is. > > Yes, Eclipse CDT likes to make huge include paths. (At least, that is > my experience using many embedded toolchain packages based on Eclipse.) > It is a PITA. It also has a painfully inefficient build system by > default. It's okay for tiny test projects - for anything serious, you > want a different project organisation and a different build system > (make, or whatever you like). This has the extra advantage of making > Eclipse CDT much faster and more convenient when you use it as an editor > and IDE. > > > Regarding the #define macros, put them all in a single header. If it > makes life easier, use the gcc option "-imacros <file>" to include it > for all compilations. A file of defines is simpler to read, edit, > comment, change and maintain than a list of "-D..." options passed to > the compiler. It also gives you more flexibility, such as using > conditional compilation to allow some macros to depend on others. > > > Of course I don't know your project at all, and don't know how realistic > these suggestions are, but hopefully you'll find them helpful. > > David >
