EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: obscure EPICS+RTEMS makefile problem
From: Michael Davidsaver <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: EPICS core-talk <[email protected]>
Date: Wed, 18 Apr 2018 10:18:46 -0700
On 04/18/2018 09:58 AM, Andrew Johnson wrote:
> On 04/18/2018 12:17 AM, Michael Davidsaver wrote:
>> On 04/17/2018 09:31 PM, Johnson, Andrew N. wrote:
>>> Why wouldn’t you put the workaround in the file CONFIG.Common.RTEMS
>>> where you don’t need a conditional test?
>>
>> Do you mean in Base or external modules?  If Base, then because I wanted
>> to hear from you first.  If external, I don't think this works with
>> $(OS_CLASS) granularity.
> 
> I was meaning in Base, I didn't consider if the issue might be in an
> external module.
Another factor is that the generated headers are being placed in ../O.Common/pv/
whereas in Base, epicsVersion.h is placed in ../O.Common which has presumably
already been created as makeEpicsVersion.pl doesn't try to do this.

>>> I haven’t looked into why you’re only just noticing this now, but there
>>> are a few possibilities that I could come up with.
>>
>> My guess is that it will come down to a mixture of not enough RTEMS/vxworks
>> builds, with a dose of GNUMake trivia thrown in.
> 
> What are the rules you're using to generate these files? See below...

https://github.com/epics-base/pvDataCPP/blob/master/src/Makefile#L34-L36

https://github.com/epics-base/pvAccessCPP/blob/master/src/Makefile#L41-L43

And now

https://github.com/mdavidsaver/pva2pva/blob/master/pdbApp/Makefile#L83-L85

>> I noticed this when adding a new generated header in pva2pva.  At first
>> I assumed it was a dep. problem on my end.  However, while a clean
>> sequential (not -j) build was always successful.  A clean parallel build
>> would sometimes fail.  When it did fail, a sequential rebuild would also
>> fail.  Which is when I noticed the missing '-p'.
> 
> I know what you're doing wrong, please generate those version headers in
> the host build only and *not* in the other build targets. Why?

Ok, fair enough.  I didn't start with this mostly because the rule for
epicsVersion.h doesn't.  Although presumably it should, for the reasons you
give.

Is this a case for

> ifeq ($(T_A),$(EPICS_HOST_ARCH))

or something more clever?

References:
obscure EPICS+RTEMS makefile problem Michael Davidsaver
Re: obscure EPICS+RTEMS makefile problem Johnson, Andrew N.
Re: obscure EPICS+RTEMS makefile problem Michael Davidsaver
Re: obscure EPICS+RTEMS makefile problem Andrew Johnson

Navigate by Date:
Prev: Re: obscure EPICS+RTEMS makefile problem Andrew Johnson
Next: DBRecord client access Marty Kraimer
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: obscure EPICS+RTEMS makefile problem Andrew Johnson
Next: PVA links alpha Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
ANJ, 19 Apr 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·