Revisions and Commits
|rEVTGEN9ddc0527d591 Merge branch 'modernize'
|rEVTGEN1d084391a5af Fix clang error regarding friend declarations
|rEVTGEN6bd54964d92e Ensure successful build with gcc9
|rEVTGEN03ffce3d45c9 Some reasonably trivial changes to remove warnings under clang8
|rEVTGEN8dad424923ec Remove unused private members from EvtbTosllScalarAmp and EvtbTosllVectorAmp
|rEVTGEN9c32f5fc5ced Fix apparent variable shadowing bug in EvtPropSLPole
|rEVTGENa10ca89b3111 One small modernisation to match EvtPhotosEngine with EvtTauolaEngine
|rEVTGEN1ce388be54ec Fix warnings from clang10
|rEVTGEN24d37621f536 Modernize EvtBLLNuL & EvtBToDiBaryonlnupQCD models, replacing dynamically…
|rEVTGEN603f6890de84 Fix modernization compiler errors and warnings.
|rEVTGEN56c01564bee8 Modernise EvtBLLNuL with suggestions from Michal.
|rEVTGENb240d9114f86 Import C++ modernization changes from Gerhard Raven.
There are compilation problems, specifically private copy constructors in EvtItgPtrFunction and related classes, giving errors when auto and make_unique are used in EvtBtoXsgammaKagan, for example. Similar issues occur for
EvtRareLbToLll, EvtVubBLNP and EvtVubNLO. Could be compiler-version dependent?
Not added to this repository yet is the LHCb-only EvtBsMuMuKK model.
We may also not need EvtNoRadCorr.hh.
Added missing EvtHQET2FF.cpp bug fix for a normalisation term (f0m) that was in the LHCb version but not copied over.
Could also think about importing cmake changes from Tom:
New models need modernization: BLLNuL, BLLNuLAmp and BToDiBaryonlnupQCD, BToDiBaryonlnupQCDFF, EvtSLDiBaryonAmp.
LHCb repository uses report() for print statements while our version uses EvtGenReport(). Used the following sed-like commands to change these lines:
sed -i 's/report(ERROR/EvtGenReport(EVTGEN_ERROR/g' fileName
@jback, I think you are still compiling with C++11 using old build system. We will need CMake as soon as we are removing EvtGen from LHCb repository, so lets review Tom's changes for that and merge that into master. Then we can rebase modernize branch from master to get CMake build system into it and by that it should be basically automatic as Tom put at least C++14 into that.
I tried gcc 6.3.0 and the configure script has been modified to enable C++14, although the corresponding environment variable is still called CPP11.
The script also continues to pass the "-D EVTGEN_CPP11" boolean flag, but this is not in fact needed anymore; it was only used in EvtMTRandomEngine and this class has been modified to not require the flag.
I agree that we should move to the cmake system as soon as we can.
FYI, quite a nice way of getting a consistent environment for testing these things is to do something like the following (this should work on any system with cvmfs installed):
source /cvmfs/sft.cern.ch/lcg/views/setupViews.sh LCG_94 x86_64-centos7-gcc8-opt
(I'm assuming you're in bash here)
You can obviously modify the LCG version and the platform etc. as you wish.
NB that for the above one you'll need to use C++17
One other nice feature of using LCG views to set the environment is that these LCG releases contain some of our dependencies, so we don't have to mess around building them ourselves necessarily. They seem to get automatically picked up by cmake - as least this worked for HepMC2 when I tried it just now.
I think I've fixed all of the compilation errors and warnings, and have also added the cmake branch changes as well. To build this modernize branch using cmake, do:
git clone ssh://firstname.lastname@example.org/source/evtgen.git evtgen.git
git checkout modernize
cmake -DCMAKE_INSTALL_PREFIX=../evtgen ../evtgen.git -DHEPMC2_ROOT_DIR=HepMCDir -DPYTHIA8_ROOT_DIR=pythiaDir -DPHOTOSPP_ROOT_DIR=photosDir -DTAUOLAPP_ROOT_DIR=tauolaDir -DEVTGEN_PYTHIA=on -DEVTGEN_PHOTOS=on -DEVTGEN_TAUOLA=on
A few thoughts on the modernisation and general tidy-ups:
- We should try to follow the "rule of all or nothing" with regard to the special member functions (i.e. destructor, copy constructor, copy assignment operator, move constructor, move assignment operator), and make good use of providing default values for data members directly in the header files, constructor delegation, etc.
- It would be good to review the use of pointers/references/smart-pointers, in particular in the interface, i.e. public member function arguments, returns etc.
- We should probably decide on a code format convention, construct a clang-format config file to reflects that convention, and apply it to all files (it might even be possible to construct a hook on the repository that checks for conformance on push)
- It would be good to test everything on both gcc and clang so that we catch as many problems as we can