Re: RFC: Creating st.cmd from snippets

[Torsten Bögershausen <torsten.bogershausen@esss.se>]

>/global/st.cmd.d:   (G=GLOBAL)
>    D10_init
>    20_environment
>    30_drivers
>    D40_settings
>    70_start-ioc

>/my/ioc/st.cmd.d:   (L=LOCAL)
>    D10_init
>    40_settings
>    40_settings~
>    30_another-driver
>    R70_start-my-ioc

>"script -o st.cmd /global/st.cmd.d /my/ioc/st.cmd.d" uses the following snippets for creating the output:

>L  10_init             (L default resets the G default)
>G  20_environment
>L  30_another-driver   (implicit addition, alphabetical sorting)
>G  30_drivers
>L  40_settings         (replacing a default, ignoring backup file)
>L  70_start-my-ioc     (explicit replace)

Hej,
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".

- 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:

"script -o st.cmd /my/ioc/st.cmd.d /global/st.cmd.d"
- and as soon as e.g. 40_settings has been read from the command line via
  /my/st.cmd.d, all 40_settings in global are blocked automatically.

- Add an "-x" option to the script:
 "script -o st.cmd -x /my/ioc/st.cmd.d40_settings /my/ioc/st.cmd.d /global/st.cmd.d"
  will ignore the local 40_settings, and find and use the global.

- 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)


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.

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


HTH
Best Regards
/Torsten



"iocsniphandler -o st.cmd  /my/ioc/st.cmd.d" /global/st.cmd.d

On 09/22/2015 10:27 PM, Andrew Johnson wrote:

Hi Ralph,

On 09/22/2015 04:28 AM, Ralph Lange wrote:

https://github.com/epics-base/epics-base/wiki/Simple-mechanism-to-create-files-from-ordered-snippets-(blocks)

My original thought was that the output file would only contain a list
of iocshLoad commands for all the snippet files that it found, not that
it would read in and spit out the contents of those files. This might
result in a much simpler Perl script, but it would then have to handle
the case where the IOC's directory tree looks different to the build
host. Your solution has different areas of complexity and simplicity but
overall is probably equivalent.

A few comments & questions on your document:

1. Why the design D03 for no dots in snippet filenames? I would suggest
a requirement that filenames all have the same specific extension such
as .cmd or .ish. GNUmake pattern rules are hard to get right without a
unique extension to hang them onto.
2. The pattern rule that runs the script will need a wildcard dependency
for each snippet directory, but then just removing a snippet file would
be insufficient to trigger a rebuild. Not sure this is going to be easy
to get right even when snippets have an extension.
3. R21 probably needs a bit more detail, e.g. where you set macro
values, and how expansion should handle environment variable macros in
the snippets. BTW there is an EPICS::macLib Perl module for when you get
to implementation, don't go writing your own.
4. D92 -- is the idea to add rules to base/configure/RULES.ioc or put
them in the iocBoot/ioc*/Makefile itself?

That's all for now, I may have more ideas later in the process.

- Andrew