EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  <20252026  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  <20252026 
<== Date ==> <== Thread ==>

Subject: Re: Stopping DB and DBD files being copied to top level
From: "Wells, Alex \(DLSLtd,RAL,LSCI\) via Tech-talk" <[email protected]>
To: "Johnson, Andrew N." <[email protected]>, "[email protected]" <[email protected]>
Date: Fri, 1 Aug 2025 13:22:05 +0000
Hi,

Thank you for suggestions. I ended up using the INSTALL_LOCATION method, as while the TARGETS worked fine for DB and DBD files that I was building myself, it did not seem to work for ones I was pulling in from external support modules. I think there would need to be more work done to make using the TARGETS method work for this case.

Thanks,
Alex Wells


From: Johnson, Andrew N. <[email protected]>
Sent: Thursday, July 31, 2025 9:49 PM
To: Wells, Alex (DLSLtd,RAL,LSCI) <[email protected]>; [email protected] <[email protected]>
Subject: Re: Stopping DB and DBD files being copied to top level
 
You don't often get email from [email protected]. Learn why this is important
Hi Alex,

I have a couple of suggestions for you. The first is to not use the TEST* variables at all, and instead have your Makefiles set the INSTALL_LOCATION variable which controls the parent directory of the db, dbd, include, bin and lib install directories for files installed by that Makefile. You can point that to an absolute path, or set it to a path relative to the O.$(T_A) directory below that Makefile, e.g.
INSTALL_LOCATION=../../install
INSTALL_LOCATION=$(TOP)/iocBoot/iocTest1
I recommend not pointing it to the App directory itself (../..) since it’s very easy to confuse the install directories there with your Db, src and other subdirectories (and on Windows the Db and db paths would refer to the same directory on a case-independent file system, possibly resulting in chaos and lost data). There is no make target that will automatically delete the installed files or directories if you use this approach, and it isn’t trivial to reuse components built in one App directory within an IOC built in another App directory.

Alternatively, you don’t need to add your .dbd and .db files to the DBD and DB variables for them to be created by a Makefile. Those variables are used to request that the named files be installed after creation, and since you don’t want the installation part you can add any files that need creating to the TARGETS variable instead. However the rules in configure/RULES.Db which build them do create them in the O.Common directory instead of O.<target> so you need to prefix the filenames in the TARGETS variable with $(COMMON_DIR) for that to work. More details below...

If you set a TESTDBD variable in an App/src/Makefile (which doesn’t currently do anything) adding this line to it will cause the files in it to be created as they would by setting the DBD variable, without installing them:
TARGETS += $(TESTDBD:%=$(COMMON_DIR)/%)
If a .dbd file already exists in the source directory you should not add it to TESTDBD though; only set the variable for files that need to be created.
If you’re building a record type in your App/src directory, you would add this line to make it generate the header file from your *Record.dbd file:
TARGETS += $(TESTDBDINC:%=$(COMMON_DIR)/%.h)

Similarly for .db files, your App/Db/Makefile should add files that need to be created to the TESTDB variable and add this line:
TARGETS += $(TESTDB:%=$(COMMON_DIR)/%)

I haven’t tested that last one, but I’m pretty sure it will work.

In all cases the lines above should appear somewhere between the two “include” statements in the Makefile.
If this works and you think it sufficiently useful we could consider adding the above to the EPICS build rules — file an issue against EPICS Base in that case to request it.

HTH,

- Andrew


-- 

Complexity comes for free, Simplicity you have to work for.


On 7/31/25, 6:24 AM, "Tech-talk" <[email protected]> wrote:

Hi Tech Talk,

I'm currently trying to build what is in effect two IOCs inside one EPICS folder structure. This is to allow a shared EPICS configuration folder (and various scripts), but keeping the two IOC builds separate inside their own "App" folders.

This works quite well for the executables as I can use the "TESTPROD_IOC" variable, which causes the executables to only be built into the "App/src/O.$(T_A)" directory. However, there is no similar variable for DB or DBD. This results in my top level directory ending up with "db" and "dbd" folders, full of built files from both my IOCs which I do not want. Especially as some file names conflict and they override eachother.

Is there any way to modify the Makefiles to stop this behaviour?

Thanks,
Alex Wells

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom.

References:
Stopping DB and DBD files being copied to top level Wells, Alex (DLSLtd,RAL,LSCI) via Tech-talk
Re: Stopping DB and DBD files being copied to top level Johnson, Andrew N. via Tech-talk

Navigate by Date:
Prev: Re: Stopping DB and DBD files being copied to top level Johnson, Andrew N. via Tech-talk
Next: Re: help requested about motorPI module Dariush Hampai via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  <20252026 
Navigate by Thread:
Prev: Re: Stopping DB and DBD files being copied to top level Johnson, Andrew N. via Tech-talk
Next: AreaDetector Collaboration Meeting - August 7th Érico Nogueira Rolim via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  <20252026 
ANJ, 19 Mar 2026 · Home · News · About · Talk · Base · Modules · Extensions ·
· Distributions · Download · Documents · Links · Licensing ·