Nonstandard use of external libraries

[ralphlange]

In opcUaDevSupApp/Makefile, the way that the external SDK is being used is quite non-standard: libraries from the SDK are copied (installed) in the application.

In the case of static (.a) libraries, the libraries should be used in place (in the SDK location). Once they are linked into the binaries or generated library, they are not used anymore.

In the case of static (.so) libraries, the user should have the option of copying those into the application (so that they are deployed with the created library or binaries) or using them in place (in the SDK location) assuming they will be installed in target systems as a dependency of the device support.

[bkuner]

Is done with the latest update

[ralphlange]

Well, that's not really true. opcUaDevSupApp/Makefile contains

EXTLIB_INSTALLS += $(INSTALL_LIB)/libuastack.so
[...]
build: $(EXTLIB_INSTALLS)
[...]
$(INSTALL_LIB)/lib%.so : $(UASDK)/lib/lib%.so
    $(ECHO) "Installing $@, $<"
    $(INSTALL) -d -m 555 $< $(@D)

which unconditionally installs libuastack.so from the external location into the device support module.

[ralphlange]

So ... before issuing another PR, I will try to outline the situation.

In terms of SDK shared library deployment, there are three common use cases we should cover:

1. SYSTEM The SDK libraries are packaged using the system package manager. Developments and production systems will have the required shared libraries in a system location (i.e. included in the loader configuration). Development systems will have the header files in a known location, and may have static libraries in the system location.
2. PROVIDED The SDK libraries are centrally deployed or provided (e.g. NFS), but not in a standard location. Developments and production systems will have the required shared libraries in a non-standard location. Development systems will have the header files in a known location, and may have static libraries in the non-standard location.
3. INSTALL The SDK libraries and header files are only available on the development system. The shared libraries must be included in the IOC application for deployment.

In terms of STATIC vs. DYNAMIC build, the following applies:

4. DYNAMIC Case 1. and 2. do not need any special treatment. It is the user's task to provide the libraries on the production system. In case 3. all required dynamic libraries have to be copied (installed) into the application.
5. STATIC All library dependencies are resolved during linking. In no case any file needs to be deployed on production systems or installed into the application.

All the above complies with the SDK license, as no header files nor API documentation is being deployed or used outside of the development system.

Configuration uses three variables: UASDK = <location of the Unified Automation SDK> UASDK_DEPLOY_MODE = SYSTEM | PROVIDED | INSTALL SHARED_LIBRARIES = YES | NO

These should be set inside the CONFIG_SITE or an CONFIG_SITE.local file.

@bkuner, do you agree?

What should be the default for the UASDK_DEPLOY_MODE? I would propose SYSTEM (or PROVIDED) for Linux. @rvuga: What would be the most common option for Windows?

[ralphlange]

Oops - sorry for the noise. I will remove the reference until this is ready to be pulled.

[ralphlange]

Update: I just realized a mistake. Since this is a module building a library (and not building an IOC), the static libraries have also to be copied into the application in the INSTALL (3.) case.

In terms of STATIC vs. DYNAMIC build, the following applies:

4. DYNAMIC Case 1. and 2. do not need any special treatment. It is the user's task to provide the libraries on the production system in the right location (1. system location or 2. as configured) In case 3. all required shared libraries have to be copied (installed) into the application.
5. STATIC Case 1. and 2. do not need any special treatment. It is the user's task to provide the libraries on the production system in the right location (1. system location or 2. as configured) In case 3. all required static libraries have to be copied (installed) into the application.

[rvuga]

Hi, sorry for late reply.

For Windows the most common use case is the following:

2. PROVIDED = Yes For example, the SDK is installed to C:/Tools/....
3. INSTALL At the moment only dlls are provided by UnifiedAutomation's SDK so people will want to ship these bundled together with the application (e.g. included in the installer or similar).

Our use case is anyhow a bit special. We build EPICS base and all supporting modules statically and link against dlls. And because dlls requires a different CRT (at least for pre-VS14 versions) we've changed default EPICS base build configuration to use dynamic CRT for static builds as well... That said for Windows the only viable option is to have the SHARED_LIBRARIES set to Yes.

[ralphlange]

Sorry - the question about PROVIDED/INSTALL is meant a bit different. Say that you are running a couple of IOCs from different TOP structures on a single Windows host. Would you assume that the user has one installment of the SDK DLLs in a specified place (PROVIDED), or would you assume that each IOC should find a copy of the SDK DLLs in the same directory as the IOC binary (INSTALL)?

[rvuga]

So if I understand correctly, you are asking which would be the common option that the users would prefer? It is hard to say, both are valid choices. If you run several IOCs, of which one may need a different SDK version than the others, then the INSTALL option may be less painful.

[ralphlange]

Sure. I'm just trying to find out if in the Windows world (that I hardly know) things would be handled somehow completely different, making one of the options very unlikely or very likely to be the most common one.

Currently, my leaning is to make PROVIDED the default in both worlds. That would be the most simple approach, needing less specific stuff and documentation. Anyone handling things differently can just set things in their CONFIG_SITE.local to whatever they need.

[rvuga]

Yup, that sounds good.

[ralphlange]

Closed by merging the PR #32