Experimental Physics and
Industrial Control System

"Mooney, Tim M." <[email protected]> · Thu, 4 Dec 2014 18:14:12 +0000

Hi Ralph,

Good suggestions.  I will do some of them now (that is, in synApps 5.8, which is imminent, and which must work with either 3.14 or 3.15), and leave the rest for synApps 6.x, in which modules may or may not require 3.15.

Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

________________________________________
From: [email protected] [[email protected]] on behalf of Ralph Lange [[email protected]]
Sent: Thursday, December 04, 2014 7:31 AM
To: EPICS Tech-Talk
Subject: Re: FW: EPICS 3.15.1

On 03/12/2014 20:44, Mooney, Tim M. wrote:
> I agree with a lot of this.
>
>> The more common pattern is to have <module> export <module>.dbd for
>> inclusion by applications, and I would lean towards proposing synApps
>> make a step in that direction.
> I've come to agree with this, mostly because people's first guess seems often enough to be that "module.dbd" is what they should include.  However, it's not the sort of change you can creep up on, as far as I can tell; you either go there or you don't, and I'm wary of causing configuration trouble for users who want to upgrade existing applications.

Upgrade paths are always ... what about this.

If you decide to e.g. name your example and test dbd files
<module>Example.dbd or <module>Test.dbd, you can have <module>.dbd and
<module>Support.dbd as identical files (or file plus link) in the
"outer" support module for as long as you want to stay compatible.

User applications were not supposed to include <module>.dbd files from
synApps in the first place.
It was tolerated in 3.14, it will fail in 3.15, and thus has to be
changed anyway. Making <module>.dbd the correct file to be included
might in the end save users from trouble: If their application was
already set up correctly, the "new" <module>.dbd will just work. If
their application was not set up correctly, 3.15 requires it to be
changed anyway. Why not change it to import resources under the final
<module>.dbd name?

At some point (before you remove the <module>Support.dbd files/links),
your synApps version update script for user applications can just
replace <module>Support.dbd with <module>.dbd - at that point this
should work, as these two files will have been the same for some time.

>> Tests and examples should rather be moved into embedded self-contained TOP structures - 3.15 provides
>> convenient Makefile rules to do that.
> That sounds pretty good.  I'll look into it.

It keeps the module, its tests and examples nicely in the same source
structure (= code repository), which is good as they are usually
developed in parallel.
At the same time it completely modularizes the source code and
de-clutters the generated libraries, resources, and binaries, making it
very obvious which belong to which part.

The base rules for this are new and basic. If you find anything not
working or not working as expected ... happy to improve the mechanism.

Cheers,
~Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System