From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id E729B385840A for ; Thu, 22 Sep 2022 16:50:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E729B385840A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x532.google.com with SMTP id a41so14486495edf.4 for ; Thu, 22 Sep 2022 09:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=pTwByvpECsS9nWGFUb2b2NsbNwZv0gaZYhv9nmCnCTc=; b=Bfq/8kPbuRnXugtefW8SwZFDdfdfalf4TJAQaB8frvkxu/AXPOMu3pyJ8AQsDLNqud iVXVaPCZGJHn3l+9qfbgD4CWe6+9rF+KFOuFABDbfxnoIQB/O97yztveVGbQbsFLAxB/ WvwP96ftrHnTA1AZnZY8LV4hvXs6FQ8EotEtk3Y+t2fiRBuneZnrAethe23gWo3lgclD +9cB5i1laW00BL0ikenwu7vNSO3srNsVsfr4hysdNxEkQ1ljxgBsYbFPeVkVFBjyOBug usU+H/T3BKtmd3bcOpVlhfvnVweh7fVmf50XHd64p+Y43j3q2ToFo09FdPcsdHgPr9XQ Yt5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=pTwByvpECsS9nWGFUb2b2NsbNwZv0gaZYhv9nmCnCTc=; b=GgKkDRP89TSJsPZU0GdQ67FtSy/NTe+F+KbT4hhm5gBNdcNtWkOC4RwCYkcZ1e5hs1 RkXoNoyMm6hm2V48cX4OmznnPuKClxC4XXwHGX4Wha7JuhzcHGx8B33A/8XmW/Ta7hvo WboKkO6ajaoe69fRUk4FXxewb+gabjAMmIMWtqM0fIEPmTNsFpOaw37a5RXrUTIbjYwW UN14gTY4+N/I5/VVnHLwHPlwz6Ro/WK6d/Y4/S5eD5l9eQ+xmQw0IEICVcPOY9YRMgw0 ChVWVNLn0RDrkLz/Cv5BUTz5FVIvd+bPidqfR0zKYaX1BLhmWZCXRvh8/cvWNW4DREyn 4e0A== X-Gm-Message-State: ACrzQf0qD26vXGM4pWbgFtAwmn9Dt6sTe3clBmg6H+v7v79iZiE/X0x6 6rPgNFGkwzbI0HvAB8tHQIdXIkJ2X2u1NTwpEog= X-Google-Smtp-Source: AMsMyM6LJx346snoQI5QxqYiLpAeJwyFyzQasUoqdMdz7WszFzkICBfUF3rKPfqv4EnmX7KKtGWrAzGZxFe5xqSpq00= X-Received: by 2002:a05:6402:3486:b0:451:b8d3:c52c with SMTP id v6-20020a056402348600b00451b8d3c52cmr4169104edc.406.1663865423668; Thu, 22 Sep 2022 09:50:23 -0700 (PDT) MIME-Version: 1.0 References: <51543dff-d479-5e6e-e046-46ce9e64c354@126.com> In-Reply-To: <51543dff-d479-5e6e-e046-46ce9e64c354@126.com> From: mizo 91 Date: Thu, 22 Sep 2022 18:50:12 +0200 Message-ID: Subject: Re: CreateProcess No such file or directory To: LIU Hao Cc: gcc-help@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000882cab05e946dbbd" X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000882cab05e946dbbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C5=BCytkownik LIU Hao napisa= =C5=82: > =E5=9C=A8 2022-09-22 22:55, mizo 91 =E5=86=99=E9=81=93: > > 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 =3D 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 > > --000000000000882cab05e946dbbd--