Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 2 Feb 2017 12:59:24 +0100

[forgot to add the list]

On 02.02.2017 10:00, Luca Cavalli wrote:
> I have a IOC using synApps 5.8 (for the "transform" record) and sequencer 2.2.4.
> I cloned my IOC from XXX reference IOC in synApps as suggested by documentation.
> If I set SNCSEQ variable pointing to my sequencer 2.2.4 installation on top of
> my IOC RELEASE file, it gets ignored and my state machines are compiled with the
> sequencer included in synApps (2.2.1). If I set SNCSEQ at the bottom of RELEASE,
> this error message is printed and compilation stops:
> 
> [...]
> perl /opt/epics/base/bin/linux-x86_64/convertRelease.pl checkRelease
> 
> Definition of SNCSEQ conflicts with SUPPORT support.
> In this application a RELEASE file defines
>         SNCSEQ = /opt/epics/modules/seq-2.2.4
> but SUPPORT at /opt/epics/support defines
>         SNCSEQ = /opt/epics/support/seq-2-2-1
> Definition of SNCSEQ conflicts with SSCAN support.
> [...]

This is because parts of synApps depend on the sequencer. The
convertRelease.pl script checks that the application and all its support
modules form a consistent set, which means the same version of every
module is used everywhere.

You need to replace the sequencer in synApps with the new version before
compiling synApps. This is not too difficult.

> Setting SNCSEQ in my src/Makefile works, but is it the correct approach?

No. The convertRelease.pl is there to help you to avoid inconsistencies.

> Is it possible to make synApps (and its sequencer installation used internally)
> and an external sequencer installation coexist?

It is certainly possible but it may involve serious Makefile hacking
inside synApps.

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." ― Scott Adams

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System