public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: mizo 91 <mizo91@gmail.com>
To: LIU Hao <lh_mouse@126.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: CreateProcess No such file or directory
Date: Thu, 22 Sep 2022 16:55:23 +0200	[thread overview]
Message-ID: <CAGt5VgEeUOTJFz2NGsqzVN0N+GoyBy8m-_+ytgdXckav89Syew@mail.gmail.com> (raw)
In-Reply-To: <fa6c35c1-3ec4-d72f-b234-b538ce74e223@126.com>

[-- Attachment #1: Type: text/plain, Size: 2745 bytes --]

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
>

  reply	other threads:[~2022-09-22 14:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20 16:02 mizo 91
2022-09-20 16:18 ` Richard Earnshaw
2022-09-20 17:17   ` mizo 91
2022-09-20 22:27     ` Tamar Christina
2022-09-21  2:42       ` fedor_qd
2022-09-21 15:27         ` mizo 91
2022-09-21 15:41           ` Tom Kacvinsky
2022-09-26  6:58           ` Re[2]: " fedor_qd
2022-09-22  6:44 ` LIU Hao
2022-09-22  7:35   ` mizo 91
2022-09-22  9:46     ` LIU Hao
2022-09-22 14:55       ` mizo 91 [this message]
2022-09-22 16:04         ` LIU Hao
2022-09-22 16:50           ` mizo 91
2022-09-23 17:40             ` Xi Ruoyao
2022-09-23 21:11               ` mizo 91
2022-09-24  5:13                 ` Xi Ruoyao
2022-09-24  9:28                   ` mizo 91
2022-09-24  9:51                     ` Xi Ruoyao
2022-09-24 10:20                       ` Jonathan Wakely
2022-09-23 17:14         ` David Brown
2022-09-23 20:55           ` mizo 91
2022-09-22  8:19   ` Jonathan Wakely
2022-09-22  8:42     ` Jonathan Wakely
2022-09-22  9:48       ` LIU Hao
2022-09-22  9:50       ` mizo 91

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGt5VgEeUOTJFz2NGsqzVN0N+GoyBy8m-_+ytgdXckav89Syew@mail.gmail.com \
    --to=mizo91@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=lh_mouse@126.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).