Sounds good, I can work around the problem for now. I understand the
reason for the change to the dbd depends, because I used to suffer with
the problem that fixed, i.e. .dbd files not being updated when they
needed to be.
I never used the 3.14.9 release, which is why I am only seeing the
problem now.
Thanks,
Mark
-----Original Message-----
From: Andrew Johnson [mailto:[email protected]]
Sent: Monday, October 27, 2008 12:54 PM
To: Mark Rivers
Cc: Core-Talk; Janet Anderson; [email protected]
Subject: Re: EPICS build problem/question
Hi Mark,
On Monday 27 October 2008 11:31:12 Mark Rivers wrote:
>
> In the 3.14.10 tree the linux-x86 build fails with the following
error:
>
> ../O.Common/dxp.dbd.depends:3: *** target pattern contains no `%'.
> Stop.
> So the problem file is O.Common.dxp.dbd.depends. On 3.14.8.2. this
file
> contains the following:
>
> *******************
>
> # DO NOT EDIT: This file created by mkmf.pl,v 1.5 2002/03/25 21:33:24
> jba Exp $
>
> ../O.Common/dxp.dbd : ../dxpSupport.dbd ../dxpRecord.dbd
>
> #Depend files must be targets to avoid 'No rule to make target ...'
> errors
> ../dxpSupport.dbd :
> ../dxpRecord.dbd :
>
> ******************
>
> On 3.14.10 this file contains the following:
>
> # DO NOT EDIT: This file created by mkmf.pl,v 1.5 2002/03/25 21:33:24
> jba Exp $
>
> ../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/base.dbd
> ../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/asyn.dbd
> ../O.Common/dxp.dbd : J:/epics/devel/mca/6-10/dbd/mcaSupport.dbd
> ../O.Common/dxp.dbd :
J:/epics/devel/calc/2-6-5beta/dbd/calcSupport.dbd
> ../O.Common/dxp.dbd : J:/epics/devel/sscan/2-6-2/dbd/sscanSupport.dbd
> ../O.Common/dxp.dbd :
J:/epics/devel/autosave/4-4beta/dbd/asSupport.dbd
> ../O.Common/dxp.dbd : ../dxpSupport.dbd
> ../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuGlobal.dbd
...
> So only in 3.14.10 does that file contain absolute paths that are
> causing the problems.
The new version of the file is correct, whereas the old one was wrong
since it
would not cause the dxp.dbd file to be rebuilt when one of its
dependencies
from a different support application was modified. This was changed in
R3.14.9 by the way, it's not a new behavior in R3.14.10.
The problem is that we're not putting that .depends file in the right
directory; it obviously needs to be architecture-specific to work
properly
with Windows, so it should go into the O.$(T_A) directory rather than
O.Common. However we currently only create the .depends file in the
same
rule as the target it relates to. Since there isn't a separate make
rule for
it, moving the .depends file to O.$(T_A) would mean that only the first
architecture to build a shared installation would actually create
the .depends file. The other architectures would have no reason to
rebuild
the target file, so would never build its .depends file either. This is
obviously broken behavior as far as their dependencies are concerned
though,
and fixing it it would mean significant changes to the build rules which
we
don't want to do on the day of the 3.14.10 release.
I don't want to delay R3.14.10 any longer, although it looks like we're
going
to have to come out with a 3.14.11 release in a fairly short timescale
to fix
up a number of issues like this.
- Andrew
--
Talk is cheap. Show me the code. -- Linus Torvalds
- References:
- Re: EPICS build problem/question Andrew Johnson
- Navigate by Date:
- Prev:
Re: EPICS build problem/question Andrew Johnson
- Next:
Re: EPICS R3.14.10 version number Andrew Johnson
- 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:
Re: EPICS build problem/question Andrew Johnson
- Next:
Re: EPICS R3.14.10 version number Andrew Johnson
- Index:
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|