EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20232024  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  <20232024 
<== 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
(https://epics.anl.gov/tech-talk/2023/msg00595.php): the last command, before freeList.html, is *compilation* of epicsTempFile.cpp.  But instead of immediately stopping, the build process continues and stops a bit later because of absent epicsTempFile.o, which should have been made by g++.

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.

# Extra rule since asLib_lex.c is included by asLib.c
asLib$(DEP): asLib_lex.c
asLib.c: asLib_lex.c

# Ensure that lexer and parser are built before they are needed
asLib.c: $(EPICS_BASE_HOST_BIN)/antelope$(HOSTEXE)
asLib_lex.c: $(EPICS_BASE_HOST_BIN)/e_flex$(HOSTEXE)
asLib_lex.c: $(INSTALL_INCLUDE)/flex.skel.static

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.

Replies:
Re: EPICS 3.15.9 build system weird behaviour upon missing g++ Dmitry Yu. Bolkhovityanov via Tech-talk
References:
EPICS 3.15.9 build system weird behaviour upon missing g++ Dmitry Yu. Bolkhovityanov via Tech-talk
Re: EPICS 3.15.9 build system weird behaviour upon missing g++ Johnson, Andrew N. via Tech-talk
Re: EPICS 3.15.9 build system weird behaviour upon missing g++ Dmitry Yu. Bolkhovityanov via Tech-talk

Navigate by Date:
Prev: RE: OMS MAXnet motorOmsAsyn module’s autosave Mark Rivers via Tech-talk
Next: Re: Problem using ADPICam driver Jörn Dreyer via Tech-talk
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  <20232024 
Navigate by Thread:
Prev: Re: EPICS 3.15.9 build system weird behaviour upon missing g++ Dmitry Yu. Bolkhovityanov via Tech-talk
Next: Re: EPICS 3.15.9 build system weird behaviour upon missing g++ Dmitry Yu. Bolkhovityanov via Tech-talk
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  <20232024 
ANJ, 28 Apr 2023 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·