EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: EPICS R3.14.9 and vxWorks
From: "Ernest L. Williams Jr." <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: "Kasemir, Kay" <[email protected]>, "Thompson, David H." <[email protected]>, [email protected], [email protected]
Date: Tue, 10 Apr 2007 09:54:54 -0400
Hi Andrew,

Sorry to bring up the following issue again:

I suppose there will be some sites that move into vxWorks 6.x but still
have vxWorks 5.5 targets as well.  What recommendation do you have to
handle this?  We could have to separate versions of EPICS BASE.
Does no good to change the VXWORKS version number in the config files as
it will simply overwrite libraries for vxWorks 6 or 5 depending on which
one you built first.

Of course, on my teststand I am only doing vxWorks 6.  When we migrate
to production we will have both vxWorks 5 and 6.



Problems with vxWorks build with new config file structure:
> (1) Can't build for vxWorks 5.5.X and vxWorks 6.X
> This is not good. Since our production environment includes both.
> So, vxWorks-ppc604 gets overwritten by second build of EPICS BASE
> against a different version of vxWorks.  I am sure that other sites
that
> move to vxWorks 6 will experience this.
> 
> I think we should have the config files contain vxWorks major version
> and BSP name like before.  Looks like you allow RTEMS to do this?
> For example, we are starting to use the altivec support on the
MVME5110
> but the MVME5100 does not have altivec support. 
> We could have vxWorks-ppc604_altivec, I guess.  Another example is
using
> the BSP/target name to discover whether we have a UNIVERSE or Tsi148
> interface for a DMA driver that we may write.  Having, the scheme that
> we used last time just turns into a bit more compile time and disk
> space, right?



Replies:
Re: EPICS R3.14.9 and vxWorks Andrew Johnson

Navigate by Date:
Prev: Re: my attendance of the EPICS meeting Matthias Clausen
Next: Re: EPICS R3.14.9 and vxWorks Andrew Johnson
Index: 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: [Fwd: Track on control system evolution] Matthias Clausen
Next: Re: EPICS R3.14.9 and vxWorks Andrew Johnson
Index: 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·