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

["Ernest L. Williams Jr." <ernesto@ornl.gov>]

Hi Andrew,


I read all of your comments and comply.

The only things we will have to do here at the SNS is to handle building
vxWorks 6.x apps as well as vxWorks 5.5.X apps since we will use both in
a production environment.

For that case, we will do the "vxWorks6-ppc604" trick.



Thanks,
Ernest




On Fri, 2006-12-08 at 16:25 -0600, Andrew Johnson wrote:
> 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