JCF: Issue #273: add a DUNEDAQ_DB_PATH environment variable to dbt-wo…

[jcfreeman2]

…rkarea-env

[jcfreeman2]

In order to test this:

• Rather than setting up daq-buildtools with the usual setup_dbt ... chant, you want to clone this repo, get onto this feature branch, and then source its env.sh
• Set up a work area based on the test nightly NFDT_DEV_240416_A9, as well as spack load dbe, of course. This work area uses Spack builds of the packages daq-cmake, oks, dbe and oksconfgen on their johnfreeman/daq-buildtools_issue273_oks_paths branches, same name as this daq-buildtools branch
• Among other tests, confirm that if you're working with both coredal and appdal in your work area, that edits to coredal schema objects through appdal schema modify the coredal schema file in-place in the checked out repo, not the installed coredal schema
• Also check that if you add a user-defined directory to prepend to $DUNEDAQ_DB_PATH, that if you then start adding new packages, dbt-workarea-env will get your user-defined directory to remain at the head of the colon-separated paths

[eflumerf]

Can confirm that dbe_main and schemaeditor work as expected with files loading from the sourcecode area when present.

[eflumerf]

Only possible issue I see is that now OKS does load from sourcecode by preference ALL the time
So generate_modules_test test-session df-01 sourcecode/appdal/test/config/test-session.xml is loading (for example) /home/eflumerf/Desktop/dune-daq-base/dev-dbe/sourcecode/appdal/test/config/trigger-segment.data.xml
I think this is fine, so you don't even need to build again after editing configurations before running, but something to be aware of

[jcfreeman2]

Merging after Eric's comments here and on Slack.