Skip to content

Conversation

@jwlodek
Copy link
Contributor

@jwlodek jwlodek commented Sep 17, 2025

Allow for overriding CONFIG_SITE with a .local version to facilitate building outside of the traditional areaDetector/configure structure.

Copy link
Contributor

@newville newville left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be an empty CONFIG_SITE.local instead of an empty RELEASE.local?

@jwlodek
Copy link
Contributor Author

jwlodek commented Sep 18, 2025

I think we shouldn't have either *.local as empty files, they should be ignored by this line in the gitignore:

configure/*.local

I think the empty RELEASE.local was committed by accident, this PR is removing it (along with loading the CONFIG_SITE.local if it exists to allow for the local override of that)

@newville
Copy link
Contributor

@jwlodek Maybe I am not understanding the goal. Your proposed CONFIG_SITE now includes a CONFIG_SITE.local file, no? And RELEASE still includes RELEASE.local.

Why would we require RELEASE.local and CONFIG_SITE.local but not provide empty ones by default?
What problem do empty *.local files cause?

@MarkRivers
Copy link
Member

@newville

Why would we require RELEASE.local and CONFIG_SITE.local but not provide empty ones by default?

The normal way this is done in EPICS is that RELEASE.local and CONFIG_SITE.local are not "required", because they are included with "-include" rather than "include". That means they are optional and will only be included if they exist. Those files are also normally in .gitignore so they won't show up in a "git diff", etc.

These are some examples from the asyn module:
https://github.com/epics-modules/asyn/blob/e2a281e22b4d84ba51e56428959c2dfa506a8312/configure/RELEASE#L36
https://github.com/epics-modules/asyn/blob/e2a281e22b4d84ba51e56428959c2dfa506a8312/.gitignore#L13

If you want to provide examples of the .local files then one way to do this is to create files like EXAMPLE_CONFIG_SITE.local.rhel7 as we do in areaDetector.
https://github.com/areaDetector/areaDetector/tree/master/configure

@newville
Copy link
Contributor

If CONFIIG_SITE is altered to include a file (even an optional file) named CONFIG_SITE.local, please add an empty CONFIG_SITE.local as a marker to indicate that this can be used in the build process.

Please retain RELEASE.local for the same reason.

configure/*.local should be removed from .gitignore.

The configure/*.local files will change the standard configuration compared to he main repository. That should be unusual here — no one has needed a CONFIG_SITE.local file with this module so far. This PR does not really give a concrete use case or point to a problem caused by not having such a file.

Anyway, such changes to the local build should be shown as a difference from the main repository, and should not be intentionally hidden from the user.

@jwlodek
Copy link
Contributor Author

jwlodek commented Sep 22, 2025

The reason we prefer to have the .local files not tracked by version control is that our automated deployment toolchain for EPICS software relies on generating these .local files given an input configuration. This includes modules based on areaDetector, where we generate a CONFIG_SITE.local that includes all of the conditional options, rather than using the configure directory in the areaDetector/areaDetector project, to allow for compiling different drivers with different feature sets. If they are not tracked by version control the deployed software still shows a clean history w/ git status, and makes updating to a new version just git pull && make, without needing to stash changes before pulling for example. But if the preference is to keep these empty files in version control, we can work around it.

@newville
Copy link
Contributor

@jwlodek

. If they are not tracked by version control the deployed software still shows a clean history w/ git status, and makes updating to a new version just git pull && make, without needing to stash changes before pulling for example.

Yeah, if you have a locally modified build configuration file, you would have to stash or work in another branch before pulling from the main branch. I would call that a good feature: git would be telling you that you have changed the build scripts, keeping you aware of that choice of a non-standard build.

Deliberately hiding local shims in the build system seems very odd to me.

But also: CONFIG_SITE already includes files from areaDetector. You say that you are customizing the areaDetector build. What specifically do you need to change for this module that is not covered there?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants