|
From: Andrew J. <an...@ap...> - 2013-02-18 19:14:30
|
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 |