On 22/09/2022 16:55, mizo 91 via Gcc-help wrote:
Hi LIU Hao, Following that logic, let's just get rid of response file feature while we are at it. Why encourage bad programming practices? Why maintain something that doesn't even work properly? I think this topic is very underrated and many people working with large codebases have problems because of it. For example, let's say I have a project structure of over 100+ modules. Each module uses internal headers from other modules. It's much easier to maintain a single global "include directories" list than to do it on a per-module basis. Because if something changes in one module I would have to rewrite configuraiton for all 100 modules as well. If I'm not mistaken Eclise CDT is using this kind of project configuration approach. Additionaly projects may rely on macro definitions to provide configuration values through the command line. And for large codebases, there could be hundreds of such macros. This alone can easily bring the length of compile command closer to this limit. Of course, you can define these macros in the header and add them as another dependency, but this is just a workaround, not a solution. I'm sure there are many different kinds of codebase configurations that will rely on this feature. And the people adopting these codebases would hit a brick wall. So yeah this is definitely a 'BUG'. Big one in my opinion. 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
