Re: RFC: Creating st.cmd from snippets

[Ralph Lange <ralph.lange@gmx.de>]

Hej Torsten,

Thanks a lot for your input!

On 23/09/2015 06:51, Torsten Bögershausen wrote:

some loose thinking:
- (agreed with Andrew:) I think live is easier when snippets should have an unique extension,
  so that everybody (both the human and the Makefile) knows
  what they are good for. ".iocs", ".isn" or why not ".ioc".

Point taken. I will add something to allow that.
I still like the "no dots" thing (idea taken from /etc/cron.*/ scripts on Linux) because it is an easy way to ignore all *.bk *.bak *.orig *.old ... files without having to explicitly filter all of these patterns.

- I like the numbering
- Local overrides global, how to do that:
  Does it make sense to re-order the command line, first things first,
  The first directory wins over the second:

Nah... well... matter of taste, actually.
I was thing along search path, include path, library path etc. settings. All of these are searching directories in the order they appear.
Maybe I should replace the multiple directories on the command line with one argument, which is a search path.

There are a number of systems that do configuration over multiple directories. What's needed in addition to plain combination is that a local place must have ways to replace/remove things from a global place, and a global place can provide defaults that when copied/adapted in a local place will replace the global definition.

- Do we really need the directory reading functionality ?
  Typically the shell can do the wild card expansion,
  "script -o st.cmd /my/ioc/st.cmd.d/*.ioc  /global/st.cmd.d/*.ioc"
  or the make system (not 100% sure, please correct my if this is wrong)


In terms of portability, I simply trust the functionality inside perl to be more consistent than the very different shells on all our different host platforms.

Another thing:
There is currently some "snippet development" going on here at ESS,
together with the IOC factory.
Either I can dig out some more information (if your interested), or you come and visit us to talk to the
developers directly.


That does sound interesting indeed.
I have seen two or three approaches to create st.cmd files so far, but only one was snippet based.
Well... I am afraid I won't get travel approval for asking a question about how to create a batch file. :-(

What is the time frame for the project, and the "pain factor" ?


First implementation next week (30 September), documentation and release late October (Base 3.15.3).

Pain factor? Low.
For st.cmd, I have a local requirement for something more flexible than creating a fixed blob and more comprehensive than series of series of include files with fixed names. Any EPICS installation larger than a handful of IOCs will think about creating st.cmd files, based on global parts with local extensions or overwrites.
So I thought I would want Base to provide a mechanism that is generic enough not to be a st.cmd solution only, while flexible and comprehensive enough to be an easy way to solve 90% of the prospective use cases.

On a related topic:
I really don't like TOP/iocBoot to be a source and an installation directory at the same time. That causes trouble when creating distribution packages for IOCs (have to sort out sources and Makefiles from the stuff the IOC needs), "make uninstall" etc.
For 3.16, I would rather have TOP/iocBoot be a regular source directory, and install the stuff for the IOC into TOP/ioc, which can be treated as an installation dir, being packaged, thrown away at "make uninstall" etc.

Cheers,
~Ralph