Experimental Physics and
Industrial Control System

"Dmitry Yu. Bolkhovityanov via Tech-talk" <tech-talk at aps.anl.gov> · Fri, 28 Apr 2023 22:15:24 +0700 (+07)

Hi Andrew,

On Thu, 27 Apr 2023, Andrew Johnson wrote:

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.

Thanks for pointing the direction!

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.

I'll try to, but I doubt I'm able to completely grok the operation of

EPICS build system.

(Shame on me, even the principle of "HOST_OPT=NO" functioning is still a

mystery: there are no references to $(HOST_OPT) besides 6 items in

*win32-x86.win32-x86 files, yet the "HOST_OPT=NO" does affect Linux

builds. Must be something with computed variable names...)

 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.

Thanks!  That looks like the final piece of the puzzle.

If those commands happen on GNU make's preliminary pass for "Automatic

Prerequisites Generation", then that strange behaviour with ignoring

*some* errors becomes clear: make supposes some commands can fail due to

not-yet-ready files (which are supposed to be made during preliminary

passes, and those passes can be multiple, not only one "first").

Unfortunately, the principles of what errors to ignore aren't clearly

specified (and can even change between "make" versions). Thus, the build

system behaviour looks completely weird.

 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.

Do you mean https://git.launchpad.net/epics-base/log/src/ca/legacy?h=3.15

? There's only one minor tweak (in a weird-looking code which I fail to

understand :)) after 3.15.9 release date.

Or is there any other place to look at?

The gdd

code is another area that has circular dependencies and requires compilation

during the first pass.

Oh, yeah, that very "genApps" binary :)

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.

I understand that with all my heart. I spent a lot of time trying to

learn using libcas -- wading through the thickets of gdd, aitTypes and

asynchronous IO classes. A rather thankless job.

With best regards,
Dmitry

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System