From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id D2DC038582B5 for ; Thu, 22 Sep 2022 14:55:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D2DC038582B5 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-ej1-x62d.google.com with SMTP id a26so21673793ejc.4 for ; Thu, 22 Sep 2022 07:55:36 -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=KmwH5fn7V7RKQW51Dwq9JNCDxw2istNf1EgN06AQBWk=; b=hmSnyy/taxBWyFdp/2JplyqHnnNLLJUSTm+wjcv0gwDCBMMvgyiNp4PC+rTU6vst2n 1cJ++Tai1mWJjkEsqQMm3azi5AHQVthMeYRS55PaYM/o++qWxI07kcxhBvbWZp9/5xtD BPZeU83kgacjs7H/wxr5JzyF11T/QHtEVFKGXm0dgyASwuYZWv1KEY+7XyMvx+ppEhOV dMCFJB+J0mDWthVGh2Iud6a4OIwSZ6I9W+JAcgSvbbNs5WU32jtVuTMOZkHD9VGpmSI1 eAk8vN2pfITEUOg9WayAguqJJY1dCXq1WPjft5CR7048W/qX8+D2kBWQnmdVNhJnm3Ok 32OQ== 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=KmwH5fn7V7RKQW51Dwq9JNCDxw2istNf1EgN06AQBWk=; b=SvgYeeOSVkbbfvP18ZZ65cds6Yw1M2OH/SWdxfeAKoismzuaaIwXl4Fkj2OO8FN52m YSh0ZZnbo8k4N/lUoNbY8aFUPmwB5J9kIbjz43RPiq3H4xV1faa2rwEdc5oDA7bNf92X G2JpvzEYWTH56O6G4kL4h2qHLFLrlbl86xS0eZzTviXeNU8thgIKD1wG/J64uBX3i0xj tYXCV8Pl7Y8zcCZX7sGrbO0a6WEEdnBNEOkzGN2F6QU3NdbwIZraok3tOvGvDrF1OWqx 2a7PNyANslJj4M9tRbw+8DgYYSzyBxGv8hmlROk1m0ftTTkHSmYvxANOJUWcHNjuV3J6 A7CQ== X-Gm-Message-State: ACrzQf2Vu7UK/+x5ha5w/3MV005ZB1hzvliriTM07eN+9+U2BPHwZadG brf8luIetkRgl4ChgVy/hPX8yR5/Ir0VQGde2dk= X-Google-Smtp-Source: AMsMyM5wQCnQ6q0xYH9ZKvNg5fRFFfEvzbDjy0CEYLwP+GsnhW379siWkWWj0dQC2qhKTWan7Fn67uFKPsKmJn/6ZQw= X-Received: by 2002:a17:907:2c74:b0:77d:5624:6301 with SMTP id ib20-20020a1709072c7400b0077d56246301mr3066898ejc.133.1663858534851; Thu, 22 Sep 2022 07:55:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: mizo 91 Date: Thu, 22 Sep 2022 16:55:23 +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="000000000000ed289905e9454049" X-Spam-Status: No, score=-0.7 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: --000000000000ed289905e9454049 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 napisa=C5=82(a): > =E5=9C=A8 2022/9/22 15:35, mizo 91 =E5=86=99=E9=81=93: > > 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 > --000000000000ed289905e9454049--