1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: FW: EPICS 3.15.1 |
From: | Ralph Lange <[email protected]> |
To: | EPICS Tech-Talk <[email protected]> |
Date: | 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