Re: What VxWorks version to officially support?

[Andrew J. <an...@ap...>]

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.

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.

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.

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