Good Morning!

f

Tuesday,28 January 2003

FPCLTF and CLHEP

Walter E. Brownf

Fermi National Accelerator Laboratory

ZOOM

Zoom and CLHEP 3

fPlan 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

Zoom and CLHEP 4

fWhat has Zoom developed?

• Allocator• CovMatrices• ErrorLogger• Exceptions• HepPDT• HepTuple• ISOcxx• IteratorFilter

• LinearAlgebra• Minimization• PhysicsVectors• SpecialFunctions• ValuePtr• ZMtimer• ZMtools

Zoom and CLHEP 5

fOur public documentation

http://www.fnal.gov/tf/zoom

Zoom and CLHEP 6

fZoom 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

Zoom and CLHEP 7

f…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

Zoom and CLHEP 8

fWe have distinct approaches

• Distinct coding philosophies• Distinct coping strategies/styles• Distinct build practices• Distinct usage styles by users

Zoom and CLHEP 9

fDistinct 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

Zoom and CLHEP 10

fDistinct 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 <iostream>

• In CLHEP: Compiler defects are handled in various places,

including config subdirectory Source code sometimes reflects cures

intrusively:#include "CLHEP/config/iostream.h"

Zoom and CLHEP 11

fDistinct 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

Zoom and CLHEP 12

fDistinct usage styles by users

• Zoom users write:#include "pkgname/filename.h"

• CLHEP users write:#include "CLHEP/pkgname/filename.h"

Zoom and CLHEP 13

fFurther 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

Zoom and CLHEP 14

fHow 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

Zoom and CLHEP 15

fOther 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

Zoom and CLHEP 16

fSeveral 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?

Zoom and CLHEP 17

fWhich 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 2.95.2 and MSVC6 soon

Zoom and CLHEP 18

fWhich 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

Zoom and CLHEP 19

fWhat 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

<libname>header source s

s rclib rary sources

doctu to ria ls

tes tva lida tion code

<libname>

Zoom and CLHEP 20

fWhat 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

Zoom and CLHEP 21

fLegacy 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

Zoom and CLHEP 22

fAn 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

Zoom and CLHEP 23

fA 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. Brownwb @ fnal.gov

fFermi National Accelerator Laboratory

ZOOM