Re: What VxWorks version to officially support?

[White, G. <gr...@sl...>]

Hi, thanks Andrew. Let's add this to the Wednesday meeting agenda.

One comment here, and a couple more inline. 

>From experience, each additional support configuration (eg vxWorks < 6) 
increases effort non-linearly (though maybe only ^1.5). Still, a lot, and
you have to be careful to avoid the situation in which functionality effort is
swamped by support effort. 

*Dirk* can you remind us of PSI's requirement with respect to vxWorks?

*Dirk*, *Timo*, what V4 functionality would cause PSI to invest in a Windows port?
  
Cheers
Greg

On Feb 18, 2013, at 8:14 PM, Andrew Johnson <an...@ap...> wrote:

> Hi Matej,
> 
> As far as APS is concerned I'd be OK with v4 only supporting vxWorks 6.x, but 
> many other sites (e.g. BESSY where Ralph works, and maybe Diamond but I'm not 
> sure about that) only have access to vxWorks 5.5 because the major upgrade to 
> 6 is really expensive.  Dirk had other reasons for wanting to continue to use 
> vxWorks 5.5 but I forget what they were; he might have mentioned them in an 
> email in the archive.  Anyhow, that's why I'm trying to keep 3.15 running on 
> vxWorks 5.5 if possible.  

> I would want to have an open discussion on tech-talk 
> to find out who would be adversely affected if we do have to drop 5.5.

"Show us the money." I agree, but we reserve the right to make support 
effort based on participation in the working group and on real use of V4. 
  
> 
> Any lab that has a vxWorks 6.x license should be able to upgrade as they're 
> almost certainly paying annual license fees for it, so if we do decide that we 
> can't support the 5.5 compiler then I think v4 could reasonably say that it 
> requires at least vxWorks 6.6 for gcc 4.1.2 (assuming there are significant 
> reasons for wanting gcc 4.x).
> 
> We also have to support the Microsoft Visual C++ compiler on Windows though, 
> which has its own foibles, and the MinGW compiler which combines the gcc 4.x 
> compiler with the Windows APIs.  I don't know if anyone has tried building 
> pvData and pvAccess on win32-x86 or windows-x64 yet, but my guess is that it 
> won't build because there are no epicsShare* decorations in the code.  Note 
> that it is possible to debug these on other OSs using gcc's -fvisibility 
> options.

Sure, but again let's be clear about cost benefit to the labs presently 
participating in V4. So, rather than blindly support MS if we ourselves don't
have a need for MS, I would rather we have a clear statement of what archs are 
and are not supported, plus a statement to the effect that developers for archs 
which are not in the supported list, are invited to ask for help to make a port.

Having said that, PSI I think may be persuaded to do the MS port. *Timo*?

> 
> I haven't got to installing and trying Boost with vxWorks yet — I have Jenkins 
> running on a test machine here and got it to build Base 3.15 for vxWorks 5.5.2 
> last week, but I may have to have it installed officially on a server to set 
> up a vxWorks 6.x build (the jenkins user account it runs as needs to be a 
> member of a specific Unix group to get access to the vxWorks compiler and 
> header files).
> 
> I would of course prefer that we not require Boost, but I don't want to make 
> your life too difficult.  If/when we merge the v4 code into Base we can set up 
> the build so that if the user doesn't provide a link to Boost it just won't 
> build the V4 stuff, so sites can still just use the v3 IOC alone.

Can a guru remind me for what we use boost (is it only for reference counted memory
management?). What are the implications for having no dependency on Boost? 

> 
> One suggestion: Could you at least create a wrapper with an EPICS- or pv-named 
> API, and change all the code to use that API instead of the raw Boost one?  
> Then if someone re-implements the necessary functionality locally we won't 
> have to go through and change all the places where it's used at that time, by 
> when its usage will probably have spread too widely to be able to actually 
> remove the need for Boost.
> 
> HTH,
> 
> - Andrew
> 
> On 2013-02-18 you wrote:
>> Another thing... what do you think about EPICSv4 dependency on boost?
>> Sure, it's a PITA to have additional/external dependency.
>> 
>> Matej
>> 
>> On Mon, Feb 18, 2013 at 11:10 AM, Matej Sekoranja
>> 
>> <mat...@co...> wrote:
>>> Hi, Andrew!
>>> 
>>> I am writing a document on what platforms/compilers EPICSv4 modules
>>> officially support.
>>> Year(s) ago you've written the following paragraph:
>>> 
>>> "
>>> Even vxWorks 5.4 didn't have a C++ compiler that old, although their C
>>> compiler was — they used a Cygnus C++ front end called 2.96+.  I don't
>>> think we should be targeting vxWorks < 6.x (minimum gcc 3.3.2) for new
>>> developments like this, and we could probably even require >= 6.6 which
>>> introduced gcc 4.1.2 if we wanted to. 
>>> base/configure/os/CONFIG.Common.vxWorksCommon has a list of gcc versions,
>>> look above the definition of VX_GNU_VERSION. "
>>> 
>>> I am now deciding wether to support VxWorks from 6.x or 6.6 on.
>>> It's basically gcc 3.3.2 vs 4.12.
>>> Having gcc v4 is good, however is there much of 6.0 - 6.5 installations
>>> that will be interested in EPICSv4 in next years?
>>> 
>>> Cheers,
>>> Matej
> 
> -- 
> There is no such thing as a free lunch.  When invited for lunch,
> it is best to check if you are there to eat, or to be eaten.
> -- Clive Robinson
> 
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/