Experimental Physics and
Industrial Control System

Jeong Han Lee via Core-talk <core-talk at aps.anl.gov> · Tue, 18 Aug 2020 11:26:37 -0700

Hi Michael,

CONFIG_SITE_ENV is always needed to be changed. There is no local file
support. If you can make this happen, it would be greatly appreciated.

However, I still think we need an option to override the message which
is shown in the running IOC, because it gives operators or others
wrong signs about the quality of EPICS base.

Best,
Han

On Tue, Aug 18, 2020 at 11:14 AM Michael Davidsaver
<mdavidsaver at gmail.com> wrote:
>
> On 8/18/20 11:03 AM, Jeong Han Lee wrote:
> > Hi Michael,
> >
> > Thank you for clarifying this.  Without it, so far I cannot override
> > the -dirty git describe within the ioc console.
> >
> > Do you know how to remove -dirty description? It is dirty according to
> > the git, but this is not dirty, because I didn't change anything on
> > source code, but changed CONFIG_SITE_ENV only.
>
> Our script gets this revision by running:
>
> > git describe --always --tags --dirty --abbrev=20
>
> So you could patch it to remove '--dirty'.
>
> "man git-describe" says of '--dirty':
>
> > Describe the state of the working tree. When the working tree matches HEAD, the output is the same as "git
> > describe HEAD". If the working tree has local modification "-dirty" is appended to it.
>
> So the simplest way to is to commit changes to all VCS tracked files.
> (eg. not configure/RELEASE.local)
>
> The intent of including '-dirty' is to capture the case where
> a running IOC (or whatever) may not be reproduced by a clean
> checkout and build.
>
> I'm not sure what to think about 'configure/CONFIG_SITE_ENV'.
> Do we need a CONFIG_SITE_ENV.local?
>
>
> > Best,
> > Han
> >
> > On Tue, Aug 18, 2020 at 8:07 AM Michael Davidsaver
> > <mdavidsaver at gmail.com> wrote:
> >>
> >> On 8/18/20 2:17 AM, Jeong Han Lee via Core-talk wrote:
> >>> Hi,
> >>>
> >>>    I don't know if this feature is intentionally designed.  From my
> >>> naive perspective, there is a logic to check whether option -V is
> >>> defined or not. This is a quick-and-dirty P0 patch.
> >>
> >> As I recall, '-V <ver>' was intended as a fallback if/when no VCS info
> >> is available.  So it should be overridden if any of the conditions
> >> are matched.
> >>
> >> If you always want to use a version string stored in a Make variable,
> >> then you might be better off using expandVars.pl (or just 'cat' if you're
> >> in a hurry).
> >>
> >>> $ ./bin/linux-x86_64/genVersionHeader.pl -h
> >>> Usage:
> >> ...
> >>>         -V version - Version if no VCS (e.g. '2020-08-18T08:01-0700')
> >>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System