RivetGun developers guide
What's the idea?
The idea of AGILe is to be a generator interface library, which can be built without any actual need to have any generators on the system at the time - it will use dummy header files and forward declarations rather than #includes from the generator packages. AGILe libraries hide the implementation details of the generators behind a uniform interface, defined by the Generator superclass.
Although not currently used, the AGILe namespace (and case-permutations of it) are reserved for future use. If it works well and there's an audience beyond RivetGun, then we can think about splitting AGILe off as a stand-alone generator interface library.
rivetgun and rivetgun-static?
The difference between the two executables is that the -static variant is a conventionally-linked executable, which can only run generators which are available at compile/link time. This imposes a restriction: since e.g. herwig6507 and herwig6510 are essentially identical generators, with the same symbols declared in their libraries, only one can be linked at a time against rivetgun-static.
The other version, rivetgun, is more sophisticated: it uses the runtime dynamic loading of dlopen() (actually, the libtool dlopen wrapper, LTDL) to load libraries which it never knew about at link time (although it may have an inkling about them - see ). The command line interface will be the same, but the executable can be built without any link time dependencies and can be very fine-grained in its choice of generator versions.
So far, rivetgun-static has been the main RivetGun executable, since it's a simpler idea and faster to get preliminary results from. Once the rivetgun-static command line interface is sorted, we can get on with making rivetgun work, which requires embedding a custom version of LTDL to allow dlopen'd symbol chaining. rivetgun will be the main CLI in the long term.
Coding style guide
(Copied from the equivalent page on the Rivet wiki)
I won't get militant on indentation, K&R style parenths or similar, but there are a few more important issues that should be taken as (slightly flexible) law...
- set...() methods should return a reference to *this, so that they can be chained;
- Private member variables should have a _ prefix, e.g. private: int _myfoo;;
- The same should probably go for member functions (methods);
- Header files should have a *.hh suffix, implementation files with a *.cc suffix;
- Try to minimise the #include entries in header files, especially if they refer to external library objects: binary library link dependencies are one thing, but header dependencies are usually one step too far.