在 2022-09-22 22:55, mizo 91 写道:
> 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.
> 

Such limits exist because the Windows NT syscall passes command lines via the `UNICODE_STRING` 
struct, which stores the string length as the number of bytes as an `unsigned short`. The maximum 
number of UTF-16 code units is consequently 0xFFFF / 2 = 32767.

There isn't "something that doesn't even work properly". It's just the system limit. On Linux we 
have a much larger limit (usually a few MiBs) but there is still one. Given an arbitrary repository, 
checked out at an arbitrary directory, with an arbitrary number of submodules, then it's likely that 
the limit will be hit sooner or later.


> 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 think I have to disagree here. Response files are there to work around the 8-KiB limit of command 
lines in CMD, but it cannot work around system limits. Using a 'config.h' of macros is widely known, 
accepted and preferred, rather than passing a lot of macros via command line. Similarly, if there 
are too many object files to link, a convenience library or incremental linking with `ld -r` will 
usually solve the issue. If you don't want to do these by tampering with build systems, xargs may 
help. There are a lot of mature solutions for keeping away from system limits, but generally we 
assume our users know what they're doing.


> 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.
> 
>
-- 
Best regards,
LIU Hao