ISISComputingGroup / ISISComputingGroup/IBEX
Remove use of MASTER_RELEASE
- Vorherrschende Sprache
- Keine Sprachdaten
- Sterne
- 6
- Forks
- 2
- Ø Merge
- 16 Std. 40 Min.
- Gemergte PRs (30 T.)
- 2
Beschreibung
`MASTER_RELEASE` lists all out epics modules and is a single file that can be used in any IOC. While it was convenient way to build an IOC in the past, using it has a few downsides and it is better to be explicit about which modules you really use:
- slower builds: the build system does a cross-check during build for consistent versions. For example our IOC may include the `calc` module in its RELEASE file and also include `asyn`, which too includes `calc` in its RELEASE. These must point to the same calc version. If you use MASTER_RELEASE then then there is a lot of cross checking to do of modules that you don't actually use
- potential ioc startup failures: every bin directory for the modules listed in MASTER_RELEASE gets added to the PATH environment of the IOC, depending on how long the local path on a computer is you may exceed the PATH length and get an ioc start failure. I saw this recently when i made procserv start on demand in #8558 - as i was spawning procServ from an IOC, the initial PATH was a little longer and the startup then failed with a corrupted PATH. I have mostly worked around this by excluding some of the initial environment.
We should aim to patch the most used IOCs first. If we miss one and it causes an issue, we can manually remove unused items from dllPath.bat on the instrument to fix, hence we should concentrate first on iocs below used on many instruments.
Discussed planning 10/07/2025 01:36.54
Some of these dependencies may only be used at runtime, not build time.
## acceptance criteria
* git grep used below shows no MASTER_RELEASE remaining
* MASTER_RELEASE files removed from https://github.com/ISISComputingGroup/EPICS/tree/master/configure
## notes
MASTER_RELEASE is only now used in `ioc/master` and running `git grep MASTER_RELEASE` there shows iocs remaining
- [ ] AG3631A
- [ ] AG53220A
- [ ] CONTROLSVCS
- [ ] CRYVALVE
- [ ] CYBAMAN
- [ ] DELFTARDUSTEP
- [ ] DELFTBPMAG
- [ ] DELFTDCMAG
- [ ] DELFTSHEAR
- [ ] ECLAB
- [ ] EGXCOLIM
- [ ] FERMCHOP
- [ ] FINS
- [ ] FZJDDFCH
- [ ] HAMEG8123
- [ ] HIFIMAG
- [ ] HLG
- [ ] HVCAEN
- [ ] IEG
- [ ] INHIBITR
- [ ] INSTRON
- [ ] JULABO
- [ ] KEPCO
- [ ] KHLY2400
- [ ] LINKAM95
- [ ] LKSH218
- [ ] LKSH336
- [ ] LKSH460
- [ ] MK2CHOPR
- [ ] MK3CHOPR
- [ ] MUONTPAR
- [ ] NANODAC
- [ ] NEOCERA
- [ ] PDR2000
- [ ] SAMPOS
- [ ] SCHNDR
- [ ] SCIMAG3D
- [ ] SDTEST
- [ ] SKFCHOPPER
- [ ] SKFMB350
- [ ] SPINFLIPPER306015
- [ ] SPRLG
- [ ] TDK_LAMBDA_GENESYS
- [ ] TEST
- [ ] TPG26x
- [ ] TPG36x
- [ ] TTIEX355P
Time in recording of planning meeting: 00h17m 2024/11/28
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Rechercherichtung
Beginne in ioc/master, wo git grep MASTER_RELEASE die verbleibenden IOCs identifiziert, und prüfe die MASTER_RELEASE-Dateien unter configure. Arbeite die aufgelisteten IOCs und ihre RELEASE-Konfiguration durch und überprüfe dabei die wie angegeben vermerkten runtime-only-Abhängigkeiten. Fertig ist es, wenn git grep kein MASTER_RELEASE findet und die MASTER_RELEASE-Dateien in configure entfernt sind.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Bereich
- build-system
- Issue-Typ
- Refactoring
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 35/100