Ok, if indeed this is a system limitation that cannot be avoided then why is the clang compiler not having this problem? It uses exactly the same argument interface and I was able to compile a test program with much more than 32k characters given by the response file. I understand why the limit exists and that it is a Windows specific process creation limitation. And I agree with your stand that project should be structure in a way that this limit never occures. However sometimes it's just not feasible to do because of reasons beyond your controll. I'm not going too deep into that statement :) I'm just trying to say that this border can be overcome. There is definitely room for improvement here. And if possible, why not just admit it? :) czw., 22 wrz 2022, 18:04 użytkownik LIU Hao <lh_mouse@xxxxxxx> napisał: > 在 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 > >
