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@126.com> 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
>