On 11/2/19 2:36 PM, Mark Rivers via Core-talk wrote:
This seems silly. It seems like the right solution is to simply make dbd files be architecture-dependent, rather than a single version in O.Common.
If each target <arch> has its own set of dbd files, it would need its own copies of the generated *Record.h and menu*.h include files to match, and we would have to add new dbd/<arch> and include/arch/<arch> install directories to put them in. The build system
would get a bit more complicated to support these, and builds will take a bit longer as each architecture built will have to run the conversion scripts (currently they only get run once, by the first host architecture).
We could generate common dbd/.h files by default, and require explicit configuration of arch-dependent files in the application - which would go into the additional .../<arch> directories.
Still: for that to be transparent to the IOC applications, we would have to require the IOC to have the arch-dependent directories somehow in the search path so that arch-dependency of those files doesn't show in the st.cmd.
And: if dbd files are arch-dependent, the databases themselves are likely to be arch-dependent, too... adding lots of complexity ... can of worms.
Since we have been shortly discussing perspectives for the EPICS build system during the last face-to-face meeting: At some point things would get *a lot* simpler by doing out-of-tree builds and let each target architecture have their own copy of the full installation without any internal .../<arch> directories.
Cheers,
~Ralph
