Re: Next R3.14.9 version: -pre2 or -RC1?

[Andrew Johnson <anj@aps.anl.gov>]

Hi Ernest,

Ok, I think I've finished integrating your modifications into the build 
system; here's what I've done, and some feedback on your questions.
Ernest L. Williams Jr. wrote:
> Problems with vxWorks build with new config file structure:
> (1) Can't build for vxWorks 5.5.X and vxWorks 6.X
Sorry, I'm not letting that Camel's nose in, because someone else will 
want to be able to build for both vxWorks 6.2 and 6.3 - where does this 
stop?  See below...
> This is not good. Since our production environment includes both.
> So, vxWorks-ppc604 gets overwritten by second build of EPICS BASE
> against a different version of vxWorks.  I am sure that other sites that
> move to vxWorks 6 will experience this.
It should be relatively easy to define a new target architecture 
vxWorks6-ppc604 which inherits its settings from the regular 
vxWorks-ppc604 target but overrides the vxWorks version and directory 
settings.  I do not want that architecture to appear in base though.
> I think we should have the config files contain vxWorks major version
> and BSP name like before.  Looks like you allow RTEMS to do this?
No, the numbers after the RTEMS names are all machine architectures 
AFAIK.  We do include the BSP name in the RTEMS target architecture 
because when you build an RTEMS IOC you're including the board-specific 
code into the final binary.  On vxWorks that is not necessary since we 
don't link the EPICS code with any vxWorks BSP-specific code.
> For example, we are starting to use the altivec support on the MVME5110
> but the MVME5100 does not have altivec support. 
I've added a ppc604_altivec target, which derives from the ppc604_long 
target to permit this.  EPICS makes no use of the altivec capabilities, 
but if you're building Base for a system that does do some altivec 
processing the Base code must be built with the appropriate flag set to 
avoid strange problems.
> Another example is using
> the BSP/target name to discover whether we have a UNIVERSE or Tsi148
> interface for a DMA driver that we may write.  Having, the scheme that
> we used last time just turns into a bit more compile time and disk
> space, right?
Anything like that is BSP-specific, and IMHO should appear in the 
vxWorks boot file itself.  I have three different implementations with a 
common API that drives the VME DMA engines on the VMEchip2 (MVME16x, 
MVME17x boards), the Universe-2 (MVME2100, 2700, and 5100) and the Tempe 
(MVME6100, 3100).
Alternatively you could create a local alias architecture for your 
different boards that are based on the base targets.  If you look at the 
CONFIG.Common.vxWorks-ppc604_long file in the forthcoming R3.14.9-pre2 
release you'll see how simple this is to do: you only have to create the 
relevent CONFIG.Common.vxWorks-xxxx file and tell your build system to 
compile that architecture.
> Running tests in libCom under linux-x86_64:
> Only the blockingSockTest failed all other passed:
> =============================================================
> [williams@dragon O.linux-x86_64]$ ./blockingSockTest
> 1..1
>
> A call to "assert (status == 0)" failed in ../blockingSockTest.cpp line
> 173.
> EPICS Release EPICS R3.14.9- $R3-14-9-pre1$ $2006/11/20 21:09:36$.
> Current time Fri Dec 01 2006 09:41:41.202612000.
> Please E-mail this message to the author or to tech-talk@aps.anl.gov
> Calling epicsThreadSuspendSelf()
I'm pretty sure this failed because the test requires that there are no 
CA servers running on the test machine, and that assertion failure comes 
from it being unable to bind to the CA server port.
By the way, there's now a much easier way to run all the tests in base - 
you just type 'make -s runtests' and it will run everything and 
summarize the results for you at the end.  We only need to see the 
detailed output from a particular test if it fails.
As to your patches, almost everything should now be there in the -pre2 
release.  I am not setting the -nostdlib flag because it is only used if 
you use gcc/g++ to link, which we don't.  I did a diff between two 
builds on Tornado 2.2, with and without that flag, and the results were 
bitwise identical.
- Andrew
--
There is considerable overlap between the intelligence of the smartest
bears and the dumbest tourists -- Yosemite National Park Ranger