Re: RFC: Creating st.cmd from snippets

[Andrew Johnson <anj@aps.anl.gov>]

On 09/23/2015 02:51 AM, Ralph Lange wrote:
> On 23/09/2015 06:51, Torsten Bögershausen wrote:
>> - (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 think having a unique extension avoids that problem, since backup
files usually append to or replace the extension anyway.

>> - 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 prefer Ralph's order, but I guess the IOC does use both approaches:
for definitions in DBD files the first one wins, but for field values in
DB files the last one wins. I think the "first wins" makes the most
sense when you're searching for something with a specific name such as
an include file because you stop as soon as you find it, but "last wins"
is better when you're going to pull things from multiple places and
assemble the result.

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

I do /not/ recommend using a single-argument search path, Windows would
require you to support ';' instead of ':' and I suspect that none of our
existing tools that take path arguments actually do that properly.

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

I agree, but our systems here use the iocBoot/ioc* directory for many
other files that the IOCs need: Autosave files, Allen-Bradley config,
local access security rules etc. The engineers also like to be able to
copy the st.cmd file and edit it for temporary test purposes.

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

I could see something like that as an alternative structure that we
support, but it would be very unpopular here if we forced all IOCs over
to that model. I do think there has to be a per-IOC directory available
for miscellaneous files without having to install them.

A couple more ideas:
* How about assembling the snippets inside a regular src/O.<arch>
directory and installing the output file?
* Allowing snippets to be provided by support modules listed in the
IOC's configure/RELEASE file? How would you pick which ones (there might
be architecture-specific snippets)?

I'm starting to think that being explicit about which files go into the
output file might be a better approach as Torsten suggested. The IOC
developer then has the final say as to what gets run, and nobody else
can just add a file to the global snippets directory to have their code
run on all IOCs — that could be really bad. Of course you can still use
wildcards in the list if desired for your site.

- Andrew

-- 
Light thinks it travels faster than anything but it is wrong.
No matter how fast light travels, it finds the darkness has
always got there first, and is waiting for it.
    -- Terry Pratchett, Reaper Man