EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: [solved:] no bug in build system (though questions remain)
From: Andrew Johnson <[email protected]>
To: Benjamin Franksen <[email protected]>
Cc: [email protected]
Date: Thu, 14 Dec 2006 17:54:39 -0600
Hi Ben,

Benjamin Franksen wrote:

# NOTE: The build does not check dependencies against files
# that are outside this application, thus you should run
# "gnumake distclean install" in the top directory each time
# EPICS_BASE, SNCSEQ, or any other external module defined
# in the RELEASE file is rebuilt.

I was aware of this. However, I dislike it pretty much, and I would like to ask what its rationale is.

This isn't a definitive answer because I haven't actually checked with Janet, but I suspect the reasoning for the comment goes like this:

1. The EPICS build system uses the configure/RELEASE file to point to locations of external products that are needed for this build. 2. We convert the contents of the configure/RELEASE file into a configure/O.<arch>/CONFIG_APP_INCLUDE file, which for each line in the RELEASE file defines an associated _LIB variable based on the main RELEASE variable. 3. In xxxApp/src/O.<arch>/MakefileInclude we define the product's _DEPLIBS variable and hence its dependent libraries based on those _LIB variables. 4. Make determines dependencies based on file modification times, only rebuilding a file if at least one of its dependencies is later than the last version of that file. 5. If someone changes the value of a variable in configure/RELEASE from one support application to an *earlier* build of the same support application, Make won't be able to tell that it needs to do a rebuild since all of the dependencies are still older than the target file. 6. Actually, as long as the support application versions were all built before the target last was, you can switch the pointer in the RELEASE file as much as you like without causing the target to be recompiled. 7. Changing the way the above variables are defined so they use fixed absolute paths rather than being based on other variables still won't convince Make that it needs to rebuild the target - after it has recalculated the new dependencies, the same time relationship still applies to those dependencies - the target is already newer than all of them, so it won't be rebuilt.

If you do rebuild a dependent library as you already found that it does actually cause the target to be re-linked. However as I described above Make can't protect you from switching between two older support apps, which is why we put that advice in the RELEASE file.

If you know that no RELEASE file changes have occurred you can omit the "make distclean uninstall" and a simple make from the top level may do the right thing, but as you know, we don't currently list external .h or .dbd files in the .depends file. I don't know what the cost of adding all these would be on a 'do nothing' build, but I expect there would be some negative effect.

- Andrew
--
There is considerable overlap between the intelligence of the smartest
bears and the dumbest tourists -- Yosemite National Park Ranger

Replies:
Re: [solved:] no bug in build system (though questions remain) Benjamin Franksen
References:
Bug in generated MakefileInclude? Benjamin Franksen
Re: Bug in generated MakefileInclude? Janet Anderson
[solved:] no bug in build system (though questions remain) Benjamin Franksen

Navigate by Date:
Prev: [solved:] no bug in build system (though questions remain) Benjamin Franksen
Next: Re: [solved:] no bug in build system (though questions remain) Benjamin Franksen
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: [solved:] no bug in build system (though questions remain) Benjamin Franksen
Next: Re: [solved:] no bug in build system (though questions remain) Benjamin Franksen
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·