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 015CA3858C54 for ; Fri, 23 Sep 2022 20:55:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 015CA3858C54 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 bj12so3010744ejb.13 for ; Fri, 23 Sep 2022 13:55:10 -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=fy1aC2WpnIb+i5PFBQtpTQxVXxCi4qj58Wf2Ah1+md8=; b=Msbrhj54njJbFbjnPB/s+EkShG7xxtfby5f2OtC/Ql8JQoVKJkwnXJGv36eV6e9gSd RNfgKkyfZQmQ3QATo0SWHavr+tlTcjwwAXCr46qEQtfvdn4Z+KzYhYDXAM7s7k2aGesD QNZUrQJ+/i/yHoCqGbYYSQ6XX5Fg+zqPIGTpyXs+veYqNnv5OLl9Vml+S9p3FeUUSMQp xD3Gr+JAu9sSEv6XrwAYzvXH7Ut2tWg8eAkJ0oXQ79FhhiZQ+C4XDijmOsj+MVOQzRZB eajbGa+pQo4JtV54u7HaSy2WDMI3+XBm/Q14J2HnrFouITuOw+6gviCaPdZ0F+UvNKoP Ij1A== 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=fy1aC2WpnIb+i5PFBQtpTQxVXxCi4qj58Wf2Ah1+md8=; b=ZoIOmXRXMOvK8dQWUBYYW7xwkM+306Y6TRJqKAAV0lp+9fQKpyzGsWFRP+UngQhfas nEAn5f9fqV5COdRMrn2elokJ0np6cRIbeR7wgk2QFy6568DqUFx/mdBHwxaQ5IsxWO9x KBf7aSqfSOhdoaUVpLJlx87ecXMHvQ2qJq0LqdArOshrmmUi2rxz6+aRLjgChETM06mF 1rO6wxh+vHevzna616gKqifDR4SeUjjHVQfE74c+jtjiPhI4qWhfarq9W4Q24NRvnv1z 2Kw0wQrtNzD2+ZPOcg0mXYwWzr7BSiWvNtjMwtxCmZEs4tFi3UV2AJ+6/ZR7DS0BoSVQ PUPA== X-Gm-Message-State: ACrzQf3+q7M3x9h+S9kdUOgVH8IJA+ATVQ34MXOZGIkSxLkNHHHU6u+v lzY1tWwZDJHaWxDswb3iyUHe6EvMJG5k9SWLrXo= X-Google-Smtp-Source: AMsMyM5KscnIOZfnHFq0+k67MRbPB7yJTc4Gajx5iBDnO6vMmcHw1axH4uz+7JgWSeHbY26hdx947VuGsCiHPwxQ7/E= X-Received: by 2002:a17:907:da2:b0:782:b6a:326d with SMTP id go34-20020a1709070da200b007820b6a326dmr8567561ejc.429.1663966509669; Fri, 23 Sep 2022 13:55:09 -0700 (PDT) MIME-Version: 1.0 References: <857a3e13-c5df-8c38-f3d6-c512c96033c8@westcontrol.com> In-Reply-To: <857a3e13-c5df-8c38-f3d6-c512c96033c8@westcontrol.com> From: mizo 91 Date: Fri, 23 Sep 2022 22:55:01 +0200 Message-ID: Subject: Re: CreateProcess No such file or directory To: David Brown Cc: LIU Hao , gcc-help@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000ba234305e95e6411" 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: --000000000000ba234305e95e6411 Content-Type: text/plain; charset="UTF-8" Hi David, At the begining let me thank you for seriously addressing my concern. I aggre that approach with global list of includes is not perfect. But it's been in use for so long by so many people in my company that switching to something else at this point is simply impossible. They are using Tasking compiler which comes integrated with some derivative form of Eclipse IDE. What I have to work with is preconfigured, There is a lot of auto generated code and changing the approach would require extrem amount of work which I simply cant handle on my own. I didnt invented it. I'm just trying to make it work in my Software in the loop solution for testing purpouses and not having a compiler that could handle this amount of load is a big no no for me. I will simply switch to Clang and never think about this problem again.Thank you all for you valuable sugestions. Kind Regards, Filip This all sounds like a very questionable way to organise your project. > (I hesitate to say "wrong", because people have good reasons for > organising projects in different ways, and sometimes it's just down to > personal preferences. But if I were given charge of this project as you > describe it, I'd say it's wrong and must be changed.) > > I would say that if you are listing a large number of include > directories in the include search path, you are doing things wrong. > This is especially true when you have code from different places and > different modules - you are just asking for trouble when there are > filename clashes between parts. It is much better to put the directory > explicitly in the #include statements. Alternatively, you can have > indirect inclusions - have a single directory "modules_includes" that > has an include file for each module. Those include files have nothing > but an include directive with the real module public include file, > including the directory. This "modules_include" might then go on your > compiler include path, but I'd not do that either. > > That way you can easily include the files you want, and not accidentally > include private headers that are internal to modules. It is much easier > to find what you want, and much easier to read the source code. When > you see "#include "modules_include/foo.h" ", or "foo/public.h" > (depending on which solution you use) in the source code, you know it is > the public interface for the module "foo". You don't have to wonder > which of the hundred directories it might be in or what module it is. > > Yes, Eclipse CDT likes to make huge include paths. (At least, that is > my experience using many embedded toolchain packages based on Eclipse.) > It is a PITA. It also has a painfully inefficient build system by > default. It's okay for tiny test projects - for anything serious, you > want a different project organisation and a different build system > (make, or whatever you like). This has the extra advantage of making > Eclipse CDT much faster and more convenient when you use it as an editor > and IDE. > > > Regarding the #define macros, put them all in a single header. If it > makes life easier, use the gcc option "-imacros " to include it > for all compilations. A file of defines is simpler to read, edit, > comment, change and maintain than a list of "-D..." options passed to > the compiler. It also gives you more flexibility, such as using > conditional compilation to allow some macros to depend on others. > > > Of course I don't know your project at all, and don't know how realistic > these suggestions are, but hopefully you'll find them helpful. > > David > --000000000000ba234305e95e6411--