Re: NT changes for 3.12.2

[Chris Timossi <CATimossi@lbl.gov>]

>
>How do VMS and NT cope with blderrSymTbl, which does something very similar
to make 
>errSymTbl.c?
>

Since NT only implements the client portions of EPICS (in fact just CA) I dont
include errSymTbl.c in LibCom.

>The base/src/libCom/O.*/envData.c files are identical for all target (and
host) 
>architectures at the same site, so provided you have one copy containing
your site 
>defaults you can use it for everything.
>

That's what I'm doing now, just to get things working, but I'd hoped to have a
build script for NT that at least ftp's the needed portions of the EPICS
source to an
NT machine and then builds ca.lib & libCom.lib. Since envData.h gets put in a
directory that depends on the OS (eg O.sun4), I can only get this file from
a tree 
that has been built.

>How much of base do these CA-only clients actually use - could we have a
top level 
>Make target (to be run on a Unix system) which extracts the parts of source
tree 
>for a particular non-Unix host architecture and runs any shell scripts
required?  
>There are some notes at the top of the BUILD_VMS.COM script which indicate
that 
>some automation of this kind could be helpful for the VMS target at least.
>

I think that someone building the Win32 or VMS version, should not need to
do pre-processing on a Unix machine. For envData.h in particular, a template
might be the simplest thing. All the values can be set simply by environmental
variables anyway. 

The general question of platform independent distribution is obviously harder.
I know that Object Space, who sells a STL for multiple platforms, includes a
Perl
script for configuring the software for the target platform (they include 
Perl with the distribution).

Chris