RE: R3.14.2

["Chris Timossi" <catimossi@lbl.gov>]

Jeff,

  We need to maintain a DLL interface for the sake of windows development
tools such as Visual Basic, Labview, and all the rest that natively
interface to DLLs. Such tools are very useful for building specialized EPICS
clients. EPICS base and extension applications could be statically linked
but there's probably a better way.

  While it's true that the Microsoft Foundation Class DLLs, for instance,
have release numbers as part of their file names, they are rarely
distributed by themselves. MFC DLLs are usually installed on the file system
as the result of the installation of some application that depends on them
and can take advantage of new MFC interfaces. This leaves applications
installed with older versions uneffected. This method is a two edge sword.
The existing application runs as before but if the new DLL corrects some bug
or has a performance enhancement, the older application doesnt see the
improvement. Rebuilding these applications, when there's a lot of them, is
painful so it shouldnt have to be done frequently.

  Binary installs of EPICS, at least for Linux and Windows, is long overdue
in my opinion. How much windows or even Linux software requrires a build
from source as it's distribution mechanism anymore? In this context,
including a release number in the dll's file name makes some sense. For the
sake of existing locally built clients, I dont think the release number
should change with every release of EPICS however.

Chris

> Nevertheless perhaps some of the issues that I raised could be
> discussed.
>
> In summary:
>
> 1) Should steps be taken so that the shareable libraries from
> different major releases of EPICS are not interchangeable? On
> Windows I think that this requires that they have different names
> (including the major release number).
>
> 2) We should probably be thinking about the proper structure for
> binary installs of EPICS base with the goal being that we can mix
> and match binary installs of various different extension and
> application components from different laboratories. On windows
> this would be an install script. Ken has an install script for
> both MEDM and EPICS Base, but we should probably be looking at
> how various components of epics from extensions and elsewhere can
> all be integrated together from independent binary installs. On
> Linux this would be Redhat Package Manger (RPM) installs. I am
> certainly no expert on such things, but I am wondering if the
> "application must be relinked to use an EPICS base installed in a
> different location" model is fully consistent with binary
> installs. Perhaps someone should look at how these issues are
> typically dealt with when integrating many different RPMs on
> Linux systems.
>
> Jeff
>