[Halld-offline] Offline Software Meeting Minutes, August 6, 2014

[Matthew Shepherd]

A clarification here:


On Aug 6, 2014, at 10:08 PM, Mark Ito <marki at jlab.org> wrote:

>    We thought that converting all directories to SCons should be pursued.
>    David is best qualified to carry this out. One difficulty is AmpTools.
>    He thought that others might be better at that conversion. Paul pointed
>    out that if we split some packages into a separate analysis tree,
>    AmpTools would likely make that migration. We agreed to go ahead with
>    the program of global conversion, but to save AmpTools for last.

You aren't compiling AmpTools, but instead a library that utilizes
the AmpTools interface.  I expect the port to SCons is relatively simple
for someone who knows what they are doing with SCons.  They one just needs
to be sure the path to the AmpTools headers which should be defined
by the AMPTOOLS env variable is in the "include directory"
passed to the preprocessor.

That should take care of libraries:

AMPTOOLS_AMPS
AMPTOOLS_DATAIO
AMPTOOLS_MCGEN

(This is exactly like, e.g., putting $ROOTSYS/include in a path for
compiling many other libraries.)

There is probably a secondary complication of supporting
GPU-based work, but this starts to become very platform dependent.
The main AmpTools package even doesn't handle this well as
there is no "configure" step.

The executables in:

programs/AmplitudeAnalysis

will need to have a similar path as well as library path
and linking libAmpTools (in addition to libAMPTOOLS_AMPS,
libAMPTOOLS_DATAIO, libAMPTOOLS_MCGEN).

If I can help, let me know... but I have no experience with SCons.
(I'll admit that AmpTools itself needs some work to make building
work a little better on various architectures and with various options
like MPI and GPU support -- it is on the to-do list...)

Matt