Good Morning! f Tuesday, 28 January 2003

FPCLTF and CLHEP Walter E. Brown f Fermi National Accelerator Laboratory Z O O M

f Zoom and CLHEP3 Plan of the talk Review Zoom's contents Why has it been hard to contribute Zoom packages to CLHEP? A proposal that will make it easier for Zoom and for others A small case study

f Zoom and CLHEP4 What has Zoom developed? Allocator CovMatrices ErrorLogger Exceptions HepPDT HepTuple ISOcxx IteratorFilter LinearAlgebra Minimization PhysicsVectors SpecialFunctions ValuePtr ZMtimer ZMtools

f Zoom and CLHEP5 Our public documentation

f Zoom and CLHEP6 Zoom has contributed to CLHEP … Zoom merged its PhysicsVectors package into CLHEP's Vectors :  A rather painful and time-consuming process  "If it hurts when you do that, don't do that" HepPDT was integrated with CLHEP from nearly its inception:  A less painful process  But idiosyncracies needed special attention

f Zoom and CLHEP7 … and Zoom has more to contribute Several packages seem of particular interest:  ErrorLogger  Exceptions  SpecialFunctions  CovMatrices But it is not a simple task to adapt Zoom code and CLHEP code to fit with each other:  Smooth interoperation is clearly a requirement  But idiosyncracies work both ways

f Zoom and CLHEP8 We have distinct approaches Distinct coding philosophies Distinct coping strategies/styles Distinct build practices Distinct usage styles by users

f Zoom and CLHEP9 Distinct coding philosophies For historical reasons, CLHEP often codes to lowest common denominator of supported compilers/platforms Zoom generally codes to C++ standard, and explicitly encourages its users to do the same

f Zoom and CLHEP10 Distinct coping strategies/styles In Zoom:  Compiler defects are handled by package ISOcxx, a central repository of tests, documents, and cures  Encourages standard C++ coding in most cases: #include In CLHEP:  Compiler defects are handled in various places, including config subdirectory  Source code sometimes reflects cures intrusively: #include "CLHEP/config/iostream.h"

f Zoom and CLHEP11 Distinct build practices CLHEP uses common autotools approach:  CLHEP packager uses autoconf to prepare a configure script  Client runs configure to produce makefiles tailored to platform and compiler, then runs make  Compiler options passed via command line Zoom must use SoftRelTools build system:  Predefines combinations of platform, compiler, and compiler options  Client runs srt_setup to specify which is wanted  No makefiles need tailoring

f Zoom and CLHEP12 Distinct usage styles by users Zoom users write: #include "pkgname/filename.h" CLHEP users write: #include "CLHEP/pkgname/filename.h"

f Zoom and CLHEP13 Further concerns Building:  CLHEP builds only in its source tree  Zoom is not permitted to build in its source tree Supporting duplicate source trees:  One CLHEP-oriented, one Zoom-oriented  Is certainly not feasible for Zoom  And likely not feasible for CLHEP, either

f Zoom and CLHEP14 How can we move forward together? We propose compromises, on all sides, for the common and greater good We strongly support proposals to evolve CLHEP by splitting into constituent packages:  Move away from a monolithic library  Give each package its own configure, …  Create one überconfigure, …, to build all Zoom, too, would move to such a context:  Move away from SoftRelTools  Leave a forwarding skeleton for current users

f Zoom and CLHEP15 Other benefits to a "poly-lithic" CLHEP Simplifies adding packages from future developers Increases flexibility for developers Increases flexibility for users Allows optional external dependencies:  Example: Zoom's SpecialFunctions uses gsl …  … but not everyone may want this

f Zoom and CLHEP16 Several details to be worked out Common conventions make life easier:  Easier learning curve for new users  Easier for developers to borrow from each other  Facilitates tool-building, tool-using by all Some of the issues:  Which C++ dialect?  Which autotools?  What package structure?  What names to use?  How to address legacy concerns?

f Zoom and CLHEP17 Which programming language? Catering to compiler defects is idiosyncratic, time-consuming, and error-prone:  Zoom's ISOcxx will be retired!  Its intended purpose has been fulfilled  Little or no reason to avoid standard features Strongly recommend we all adhere to C++ language per international standard:  Compilers have dramatically improved since C++ was standardized in 1997  It's time to drop egcs support for new releases; drop gcc and MSVC6 soon

f Zoom and CLHEP18 Which autotools? CLHEP today uses only autoconf Recommend automake, libtool, …, too:  Gives broader platform coverage  Automates building shared libraries, now ad hoc  Automates creating tarball variants (e.g.,.tgz )  Allows users to have multiple installations Only developers need these autotools:  Clients run configure and make, just as now  These tools are under active development; we should probably select a common version

f Zoom and CLHEP19 What package structure? Keep most of current organization Separate each library's public header sources:  Keep distinct from its other, private, source files  Everyone: #include "libname/filename.h"  Autotools can ensure build uses: - I libname

f Zoom and CLHEP20 What names to use? Keep current package names: e.g., Vector Name libraries libPkgName: e.g., libVector Put current packages in namespace CLHEP::  Except for those already using namespaces …  … which should keep their current names  Must avoid using and using namespace declarations at global scope in header sources

f Zoom and CLHEP21 Legacy issues Backwards compatibility is likely important for some current users:  Accessibility to header sources, namespaces  Accessibility to link libraries Structure a CLHEP library alongside others:  On same footing as all other libraries  Its header sources merely forward  User can use configure to create a monolithic library instead of individual libraries  Can contain common autotools utilities and cache, perhaps reducing build time

f Zoom and CLHEP22 An additional utility Useful to determine how a library was built:  Which compiler? Which compiler options?  Of use to both developers and users Other libraries have this capability:  Contemporary example: gsl ( has gsl-config)  Older example: KERNLIB Implemented by building + installing a script (via configure ) or a binary (via configure + make ) with this information embedded in it

f Zoom and CLHEP23 A case study: ErrorLogger Started with Zoom's code base:  After a few days to read autotools book + docs …  ~ 0.5 day to edit source (+ nmsp, - ISOcxx, … )  ~ 1.5 days to create and test configure and Makefile prototype files for this library + its tests  Now builds, installs, checks, makes tarballs, … Still to do:  Update documentation to reflect the changes  Improve tests to take advantage of new context  Look at portability of package's threading support  Move into polylithic CLHEP environment

FPCLTF and CLHEP Walter E. Brown fnal.gov f Fermi National Accelerator Laboratory Z O O M