Experimental Physics and Industrial Control System
|
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
<2006>
2007
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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|