public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: LIU Hao <lh_mouse@126.com>
To: mizo 91 <mizo91@gmail.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: CreateProcess No such file or directory
Date: Fri, 23 Sep 2022 00:04:28 +0800	[thread overview]
Message-ID: <51543dff-d479-5e6e-e046-46ce9e64c354@126.com> (raw)
In-Reply-To: <CAGt5VgEeUOTJFz2NGsqzVN0N+GoyBy8m-_+ytgdXckav89Syew@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2778 bytes --]

在 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

  reply	other threads:[~2022-09-22 16:04 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
2022-09-22 16:04         ` LIU Hao [this message]
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=51543dff-d479-5e6e-e046-46ce9e64c354@126.com \
    --to=lh_mouse@126.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=mizo91@gmail.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).