Hio Andrew,
> We build a RELEASE.<host-arch>.local file in the modules directory which contains the full path to EPICS_BASE for the modules to use, and in your case it still contains the old path.
> You should just be able to delete those files for all your host architectures and they will be recreated when you next run make on that arch.
Yes, that worked. But shouldn't "make clean" remove those files? I should not have to manually remove files when I update to a new version and rename the directory?
> tux% git submodule status 41d56fdf89a09617f2d5fe726fa0ecb579ca551f modules/normativeTypes (5.2.1)
> 5e793422198d4223a03164787cacbfb6cf9575fc modules/pvAccess (6.1.0)
...
Yes, that is what I see so I think I'm good.
Thanks,
Mark
-----Original Message-----
From: Johnson, Andrew N. <[email protected]>
Sent: Tuesday, December 18, 2018 11:54 AM
To: Mark Rivers <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: Re: Working on the 7.0.2 final release
Hi Mark,
On 12/18/18 11:35 AM, Mark Rivers wrote:
> make[2]: Entering directory `/usr/local/epics-devel/base-7.0.2/modules/libcom'
> configure/CONFIG:33:
> /usr/local/epics-devel/base-7.0.1/configure/CONFIG: No such file or
> directory
> configure/RULES_TOP:2:
> /usr/local/epics-devel/base-7.0.1/configure/RULES_TOP: No such file or
> directory
> make[2]: *** No rule to make target `/usr/local/epics-devel/base-7.0.1/configure/RULES_TOP'. Stop.
>
> Why is it looking for base-7.0.1 rather than base-7.0.2? The environment variable EPICS_BASE is not set.
We build a RELEASE.<host-arch>.local file in the modules directory which contains the full path to EPICS_BASE for the modules to use, and in your case it still contains the old path. You should just be able to delete those files for all your host architectures and they will be recreated when you next run make on that arch.
As to your earlier question about the submodules, in the parent module I think you just run
git submodule update
which may check them out also in the detached state, although that doesn't really matter. You should be able to replicate this output though:
> tux% git submodule status 41d56fdf89a09617f2d5fe726fa0ecb579ca551f
> modules/normativeTypes (5.2.1)
> 5e793422198d4223a03164787cacbfb6cf9575fc modules/pvAccess (6.1.0)
> d776f6eaf03c058597c05b3308636d95223b6c6e modules/pvData (7.1.0)
> 07a951c3a2bd3e95b1de24e3224e310225e3e45a modules/pvDatabase (4.4.0)
> a245adb5cfc9b4a0b0d04b630032963ecc3410d0 modules/pva2pva (1.1.0)
> b1c101578bea3610f777a1f51229eb2967dc89f4 modules/pvaClient (4.4.0)
HTH,
- Andrew
--
Arguing for surveillance because you have nothing to hide is no different than making the claim, "I don't care about freedom of speech because I have nothing to say." -- Edward Snowdon
- Replies:
- Re: Working on the 7.0.2 final release Johnson, Andrew N. via Core-talk
- References:
- Working on the 7.0.2 final release Johnson, Andrew N. via Core-talk
- Re: Working on the 7.0.2 final release Johnson, Andrew N. via Core-talk
- RE: Working on the 7.0.2 final release Mark Rivers via Core-talk
- Re: Working on the 7.0.2 final release Johnson, Andrew N. via Core-talk
- Navigate by Date:
- Prev:
Re: Working on the 7.0.2 final release Johnson, Andrew N. via Core-talk
- Next:
Re: Working on the 7.0.2 final release Johnson, Andrew N. via Core-talk
- 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: Working on the 7.0.2 final release Johnson, Andrew N. via Core-talk
- Next:
Re: Working on the 7.0.2 final release Johnson, Andrew N. via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|