[Halld-online] Comments concerning my first look at the CODA 3.0 release

Elliott Wolin wolin at jlab.org
Mon Dec 16 11:49:59 EST 2013


Hi,

Mark D is testing the CODA 3.0 release, below are a few comments of mine 
from just looking at it.  I understand a "cleanup" phase is being 
planned by the JLab DAQ group:

- codaObject package is missing, this is important for the farm manager 
and farm processes
- /3.0/Linux/bin, lib, bin64 and lib64 do not contain programs and libs 
from all CODA packages
- /3.0 does not contain links to all packages in /3.0/src
- some packages in /3.0/src not completely built, internal Linux-xxx/bin 
directory missing
- this is a "copy" release, we eventually want to check out a tagged 
release, then build it ourselves

Also, there are two bin/lib release strategies internal to CODA, and we 
prefer a third alternative.  The first is Carl's Linux-i686/Linux-x86_64 
way of doing things, the other is the /3.0/Linux/bin, lib, bin64, lib64 
way.  In neither case is the compiler identified.  I suspect Linux/bin 
and Linux/lib refer to 32-bit GCC 4.1.2, and bin64/lib64 refer to 64-bit 
GCC 4.4.x, but I don't know this.

Recall the the online uses BMS_OSNAME to label the release dirs, same as 
the offline (e.g. Linux_RHEL6-x86_64-gccxxx), and we'd like to do the 
same for CODA.  Carl implemented the CODA_OSNAME option in his scons 
files which would allow us to e.g. replace Linux-i686 with 
Linux_RHEL6-i686_gcc4.1.2 when CODA packages are built.  But this scheme 
isn't used in /3.0/Linux.

So a question for the JLab DAQ group is whether our scheme can be 
accommodated, and how it might be done.  For this first release I can 
add links here and there to make it work, but I'd like it to be 
automatic in the future.

Finally, our online build system relies on environment variables such as 
EVIOROOT.  Currently we can set these to e.g. 
/gluex/coda/3.0/src/evio/Linux-x86_64 (or eventually 
/Linux_RHEL-x86_64_gccxxx), where we assume what is in these Linux dirs 
is the same as what lives in the /3.0/Linux dir.  Or we can avoid 
pointing to the src dir if the scheme in /3.0/Linux is modified.  Note 
that we expect to find both a lib and inc dir in EVIOROOT and the others 
(following Carl's scheme).

Thoughts, comments...?

Thanks,

-- 

				Sincerely,
					Elliott
  

================================================================================


  Those raised in a morally relative or neutral environment will hold
		    no truths to be self-evident.
				

Elliott Wolin
Staff Physicist, Jefferson Lab
12000 Jefferson Ave
Suite 8 MS 12A1
Newport News, VA 23606
757-269-7365

================================================================================



More information about the Halld-online mailing list