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 czw., 22 wrz 2022 o 11:47 LIU Hao <lh_mouse@xxxxxxx> napisał(a): > 在 2022/9/22 15:35, mizo 91 写道: > > Hello LIU Hao, > > > > Thank you for your insight. In my understanding main purpouse of > response file is to overcome > > command too long issue(which can also happen on linux but is by > magnitude less likely). I imagine if > > my command is too long gcc driver should ensure that subprograms like > assembler should have recieved > > command arguments in the same way gcc did (which is through response > file). Insted the assembler > > process is spawned directly By CreateProcessA whith unwrapped arguments > by the driver which is like > > you said the reason for the error. Additionaly isnt -I flags required > for preprocessor only? Why gcc > > is trying to pass -I arguments to assembler program? Wouldnt you > consider this gcc driver bug than? > > > > > > I doubt whether there is necessity to fix this 'bug', if it has to be a > bug, after all. Normally a > user is not expected to compose a command that comprises tens of thousands > of characters. If they do > then they are likely doing something wrong; they should have split such a > source into multiple files > to reduce dependencies and passed shorter command lines to build them. > > > > -- > Best regards, > LIU Hao >
