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: Andrew Johnson <[email protected]>
To: Michael Davidsaver <[email protected]>
Cc: EPICS core-talk <[email protected]>
Date: Wed, 18 Apr 2018 11:58:01 -0500
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.

>> 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...

> 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?

1. Target builds depend on host builds, so the files are only created
once, for the host target, and there should be no problems with multiple
copies being built in parallel and clashing installations or with later
targets causing files to be installed with a newer modification time.
2. They will be in place before the target builds generate the .d file.
3. You don't have to worry about this "mkdir -p" issue.

> This is coming from either RTEMS 4.9.6 or 4.10.2.  Both install
> 'make/host.cfg', and I can't remember the order in which I built them.

I would like to not have to rely on the rules and settings from the
RTEMS build system, but I suspect that won't ever happen because of the
number of different settings that are probably needed by the different
RTEMS targets.

- 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: obscure EPICS+RTEMS makefile problem Michael Davidsaver
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

Navigate by Date:
Prev: Re: CA get of zero length array Michael Davidsaver
Next: Re: obscure EPICS+RTEMS makefile problem 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 
Navigate by Thread:
Prev: Re: obscure EPICS+RTEMS makefile problem Michael Davidsaver
Next: Re: obscure EPICS+RTEMS makefile problem 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, 18 Apr 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·