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]

:x: Build asyn 1.0.290 failed (commit https://github.com/epics-modules/asyn/commit/8cacd75dde by @jlmuir)

[AppVeyorBot]

:x: Build asyn 1.0.293 failed (commit https://github.com/epics-modules/asyn/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.