EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base
From: Jeff Hill <[email protected]>
To: Jeff Hill <[email protected]>
Date: Tue, 16 Aug 2011 00:45:23 -0000
Responding  to Andrew's comments

> There's no point publishing a separate branch for the LICENSE file changes, I will 
> update that file in the 3.14 branch and include that with the other changes when 
> I next bring bug fixes over into the 3.15 branch.

ok

> I'm not 100% convinced about separate compiler-specific include directories yet, and 
> the changes here don't cover all of the compilers we have configure/os/CONFIG files 
> for, although some of the others can probably be dropped (e.g. Borland).

The compiler specific build directories prevent accumulating NxM ifdef tests where N is the number of OS and M is the number of compilers. My guess is that we will find this infrastructure to be quite useful in other situations. When adding a change like this one is creating a proper organization so that we can have a good system. I don't think that we hoped to know about all os at the onset when adding the os directory. Note however, that if there isn't a Borland (or some other compiler) specific epicsAtomicCD.h then the default one is used which redirects to an OS specific implementation. And if there isnt an os specific implementation then they get the mutex locked version. I dont mind moving this to another branch, but it will block the atomics branch since its a prerequisite.

> So far most of the discussion has been about 3, which is a fairly minor part of the 
> branch.  I'd prefer that an -x86 target mean we compile for whatever CPU the OS 
> defaults to, but we should also support setting EPICS_HOST_ARCH to -486/586/686 as desired.

I will see if I can automate this with a perl script. As Michael mentioned however, suspect that current situation is ok for many linux - maybe the only exception is RHEL. And of course they can also fix this in a CONFIG_SITE file.

> VxWorks 6.9 supports SMP, and one of the SLAC attendees at the Codeathon is planning to ]
> update our VxWorks code to support that.

I have coded two vxWorks versions. One for vxWorks 6.6 supporting SMP, and another for before that version.





-- 
https://code.launchpad.net/~epics-core/epics-base/epicsR3.15-atomics/+merge/70642
Your team EPICS Core Developers is requested to review the proposed merge of lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base.


Replies:
Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base mdavidsaver
References:
[Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base Jeff Hill

Navigate by Date:
Prev: Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base Jeff Hill
Next: Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base mdavidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base Jeff Hill
Next: Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base mdavidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  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 ·