Add Linux support for non-system tirpc library

[jlmuir]

Add support on Linux for using a tirpc library that is not a system library.

[AppVeyorBot]

❌ Build asyn 1.0.290 failed (commit 8cacd75dde by @jlmuir)

[jwlodek]

I think in most cases in AD for example, ***_EXTERNAL specifies whether to use a version of the library built as a part of the EPICS build system or not, rather than a system version vs. source install. Maybe we could automatically use the system version if TIRPC_INCLUDE and TIRPC_LIB are not set, and we can comment them out by default? Then we wouldn't need the TIRPC_EXTERNAL.

Something like: https://github.com/areaDetector/ADCore/blob/0ebde8129e652876b7fd71b459275725f70b2da6/ADApp/commonDriverMakefile#L230

[jlmuir]

I was basically trying to be consistent with areaDetector's configure/EXAMPLE_CONFIG_SITE.local, which contains the following comment:

# Configure which 3rd party libraries to use and where to find them.
# For each library XXX the following definitions are used:
# WITH_XXX      Build the plugins and drivers that require this library.
#               Build the source code for this library in ADSupport if XXX_EXTERNAL=NO.
# XXX_EXTERNAL  If NO then build the source code for this library in ADSupport.
# XXX_INCLUDE   If XXX_EXTERNAL=YES then this is the path to the include files for XXX.
#               However, if XXX is a system library whose include files are in a 
#               standard include search path then do not define XXX_INCLUDE.
# XXX_LIB       If XXX_EXTERNAL=YES then this is the path to the library files for XXX.
#               However, if XXX is a system library whose library files in a 
#               standard library search path then do not define XXX_LIB.

But I'd be happy with the approach you proposed too. Thanks!

[jlmuir]

I also see an approach like what you're describing in measComp/measCompApp/src/Makefile. So, do you want to make the change, or do you want me to change this PR?

[jlmuir]

Didn't hear from you, so went ahead and made the change that I think you're wishing for and force-pushed. Thanks!

[AppVeyorBot]

❌ Build asyn 1.0.293 failed (commit a804e432b1 by @jlmuir)

[MarkRivers]

I think this is a slippery slope. These are the SYS_LIBS referenced in asyn/asyn/Makefile:

  asyn_SYS_LIBS_Linux += tirpc
  asyn_SYS_LIBS += usb-1.0
  asyn_SYS_LIBS += ftdi1
  asyn_SYS_LIBS += ftdi
  asyn_SYS_LIBS += gpib

If we add comments for non-system locations of tirpc, then don't we also need to add them for usb-1.0, ftdi1, ftdi, and gpib?

Can you explain why you are not installing tirpc as a system library?

[jlmuir]

Re a slippery slope, I would say that supporting all library dependencies being non-system libraries would be good. For example, I think ADSupport mostly (fully?) does this. Thinking of libraries and programs that I've built from source that are not an EPICS module, it seems that most, if not all, of them support specifying the location of all dependent libraries, includes, and programs, and do not assume system locations. That's part of writing portable software.

The reason I'm not installing tirpc as a system library is that I'm planning to package all EPICS modules that I use as pkgsrc packages. I want to use pkgsrc because it's a cross-platform package management system. This means I can have consistent builds and installs of packages on macOS and Linux and possibly others. To make the binary packages that I build of these pkgsrc packages as portable as possible, I want to build them on a minimal system platform and with dependencies satisfied by other pkgsrc packages, not system packages. This way, dependencies can be cleanly specified and satisfied for each pkgsrc package, and I don't have library dependencies that can change out from under me (e.g., the user can't remove or upgrade a system package that a pkgsrc package depends on that then breaks a pkgsrc package). And anyone who uses these packages can install a package and know that it will work. If I didn't do it this way, then there'd be no guarantee that installing a binary pkgsrc package would even work because it could depend on a set of system packages that have to be installed separately on the system in order for it to work. And then I'd have to maintain a separate list of system packages per platform (and per package if I wanted to allow the user to only install what was really needed) that the user would need to install separately in order for a given pkgsrc package to actually work. Bad business.

[jlmuir]

Another reason that's not mine but could be someone else's is, if a user wants to build and install asyn and dependencies in their home directory, for example, or some other location that does not require administrator privileges to install to. By supporting a non-system tirpc, the user could install tirpc in their home directory and then be able to build asyn against it. This situation could arise on a system where the user doesn't have administrator privileges, and they either can't ask for other system packages to be installed, or the system administrator does not want to install other system packages.