Re: CreateProcess No such file or directory

[David Brown <david@westcontrol.com>]

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