1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 <2023> 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 <2023> 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: EPICS 3.15.9 build system weird behaviour upon missing g++ |
From: | Andrew Johnson via Tech-talk <tech-talk at aps.anl.gov> |
To: | "Dmitry Yu. Bolkhovityanov" <D.Yu.Bolkhovityanov at inp.nsk.su> |
Cc: | tech-talk at aps.anl.gov |
Date: | Thu, 27 Apr 2023 12:50:12 -0500 |
Hi Dmitry, On 4/27/23 10:33 AM, Dmitry Yu.
Bolkhovityanov wrote:
Unfortunately, the build system ignores errors from not only g++ runs for depencency generation (those with -MM -MF), but ALL of them, including .cc to .o compilation (those with "-c").I remembered after I had sent my last reply that there are some cases where GNU Make's first pass is actually compiling C and C++ programs, and those are almost certainly what you are hitting, but again make is ignoring build failures then because it's still running its first pass. All (or possibly almost all) our C/C++ compilations are done using rules that run commands defined in the variables $(COMPILE.c) or $(COMPILE.cpp) and neither of them should contain the leading "-" character that tells GNUmake to continue after a failure. It is visible in my build logs excerpts There are two implementations of epicsTempFile.cpp which provide a function that are needed by the e_flex and antelope programs (versions of lex and yacc). Those programs are required by the build process in the src/libCom directory as a result of these dependency rules in src/libCom/as/RULES: # This is a Makefile fragment, see src/libCom/Makefile. The asLib$(DEP) target expands to asLib.d which gets included into the Makefile, so that causes both e_flex and antelope to be built in the first-pass of the make process for libCom. The asLib_lex.c file is generated by running e_flex on the asLib_lex.l source file, and asLib.c is created by antelope from the asLib.y source file. It's possible that removing the asLib$(DEP) rule might clean this up, but I don't know if the result will actually build. Please let me know if you find a solution that removes some of this complexity. Is there any document describing how EPICS build system is configured to ignore *some* errors (curiously, without a use of ".IGNORE:", "--ignore" or "-" before commands)?It's not not documented or explicitly configured by our build system at all, it just occurs implicitly because of the above dependency rules and the fact that the build -includes all the generated .d files. P.S. I'm trying to investigate this problem not because of "missing g++" (which is obviously a non-issue), but to understand how the EPICS build system works. Which, in turn, is needed to solve another class of problems: when something goes wrong during build, e.g. "genApps" SIGSEGVs on some architectures (due to a buggy gddUtils.h), the error isn't shown "as is" immediately but the build process continues and only the "induced" error due to a missing file is shown later.There have been several fixes committed to the 3.15 branch on GitHub since the 3.15.9 release, at least one of which related to gdd so I recommend you take a look at the branch tip in case that resolves those issues. The gdd code is another area that has circular dependencies and requires compilation during the first pass. To be honest we are only continuing to build gdd because it's needed by the Channel Access PV Gateway which many sites rely on; the original authors of that code have left the community and nobody really wants to touch it, although we do have to keep it running because we still need the gateway. HTH, - Andrew -- Complexity comes for free, Simplicity you have to work for. |