is it possible to build an areaDetector module outside of the tree?
Sure. Mark pointed out a few that do it.
For ITER's CODAC Core system, I'm building and packaging all modules separately: core, simdriver, genicam, aravis, pilatus, simba.
I tried to use ad-core as it is and failed, as it does a few things in a non-standard way that makes such separation really hard.
With one core module and many driver modules (getting more over time), I decided to help long-term maintenance by concentrating changes in the one core module.
So, changes are mostly in ad-core. I have one patch file (unchanged since ADCore 3.11) that:
- comments out all the plugins that we don't use
- sets things up correctly in configure/CONFIG_SITE
- removes all the auto-converted displays for display managers we don't use
- improves the dbd file setup to cleanly separate ad-core "AD.dbd" and the whole stack "ADSupport.dbd"
- installs iocBoot/EXAMPLE_commonPlugins.cmd and iocBoot/EXAMPLE_commonPlugin_settings.req (also renames them and puts .req into db/)
- installs make snippets ADApp/commonDriverMakefile and ADApp/commonLibraryMakefile (renames them to mark them as AD things)
With that streamlined ad-core, changes for the drivers are pretty minimal:
- setting of EPICS_BASE and AREA_DETECTOR in a RELEASE.local
- patch Makefile to include the Makefile snippets (commonDriverMakefile/commonLibraryMakefile) from their new locations/names in the install area
The stuff is using ITER's build system (uuuuhh), located on our internal (eeeehh) Subversion (whooooaa) server.
I'm happy to send the patches, though, or a combination of, e.g., core/simdetector sources that is set up this way.
@Mark: If you were willing to move upstream AD in that direction, I could be talked into preparing a Pull Request.
Cheers,
~Ralph
