Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 04 Dec 2014 14:31:06 +0100

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