Re: What VxWorks version to officially support?

[Matej S. <mat...@co...>]

Hi,

> 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 have to decide on this. Not an easy decision, however we have to
draw a line somewhere,
otherwise we will be supporting legacy systems forever. The question
is: how many there are,
and probably more important: are they thinking of EPICS V4.

> 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. Windows need to be supported.
However if you go Win you should go 100% and use MS VC++ all the way.
I do not like mingw/cygwin. James shared the same opinion and he made
pvData/pvAccess
work on Windows using MS Visual Studio, if I remember correctly.

> 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 am leaning toward idea to take a part of the boost and integrate it
to pvDataCPP, or even
better pvCommonCPP. This way there is no burdon on users.

I think David had the same idea, but putting some parts into the EPICS
base. Right?

By part of I mean: TR1 with some exceptions (mainly headers only);
lockfree, atomics (C++11 standard), move (C++11 rvalue move).

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

That matched my idea. And the wrapper API is defined by TR1 or C++11.

Matej