Closed MarkKJones closed 7 years ago
I just went with what the DAQ group does. When compiling EVIO, it installs itself in $CODA by default (unless you set --prefix explicitly).
Ole
How about having the build system look in $EVIO first, then in $CODA?
And yes, if evio.h is not present in $EVIO/include or $CODA/include, then we download the source and build it locally.
Sure, this can be done. I’ll work on it ... probably Monday before I can get to it in earnest.
Cheers, E.
Dr. Edward J. Brash Department of Physics, Computer Science & Engineering Christopher Newport University work: (757) 594-7451 cell: (757) 753-2831 www.cnu.edu/pcs
On Sep 30, 2017, at 7:15 PM, Ole Hansen notifications@github.com wrote:
And yes, if evio.h is not present in $EVIO/include or $CODA/include, then we download the source and build it locally.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
I added support for detecting an actual EVIO installation under $EVIO_LIBDIR/$EVIO_INCDIR, $EVIO and $CODA to the Make system in commit 924b792. See the commit message for details. I'll let Ed handle the SCons part.
Until it gets fixed the quick fix to the SCONS problem is edit the podd/SConstruct
Change line
coda_dir = os.getenv('CODA')
to
coda_dir = os.getenv('CODAtemp')
This will cause it to download evio instead of looking in CODA.
I should be able to get to this one this afternoon.
On Oct 2, 2017, at 12:49 PM, Mark K Jones notifications@github.com wrote:
Until it gets fixed the quick fix to the SCONS problem is edit the podd/SConstruct
Change line
coda_dir = os.getenv('CODA')
to
coda_dir = os.getenv('CODAtemp')
This will cause it to download evio instead of looking in CODA.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_analyzer_issues_144-23issuecomment-2D333593672&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=QQI4wgZ48DvzGull4QAPAA&m=nsY1TFHQUy8nAz2LXgSkkWJetW2Eoot4gtXNgSlU4CY&s=zPqPwkN1TqRgQAA2lTMD7DP_O9wMCNfcFwNRYmYMWtk&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AE1Pu6Zonq1P3yYiMi7f4FXvDpPfqhXfks5soRQCgaJpZM4PpnJX&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=QQI4wgZ48DvzGull4QAPAA&m=nsY1TFHQUy8nAz2LXgSkkWJetW2Eoot4gtXNgSlU4CY&s=yALB37MkO92R1eA-ZFsUH_WCwzOobb4ILpDft22Tv2w&e=.
For folks that are working on the cdaq cluster and using the non standard ROOT PRO installation (5.34.36) you will run into issues regarding a clean installation of hcana. From what I understand you will also run into issues utilizing the PRO installation however that is aside the point.
Currently, when one logs into cdaql1 the default ROOT is source to the PRO version. If one then switches to say 6.08.00 via. the command ‘source /apps/root/6.08.00/setroot_CUE.csh’ then your LD_LIBRARY_PATH and PATH environment variables will still contain stale links to the PRO version of ROOT. With the newest updates to Scons, this will cause the build of hcana to fail.
The hack to solve this issue is that one needs to remove the PRO version of ROOT in the aforementioned paths. This can be accomplished with the following shell commands:
setenv PATH echo $PATH | perl -pe "s[/apps/root/PRO/root/bin][]g;"
setenv LD_LIBRARY_PATH echo $LD_LIBRARY_PATH | perl -pe "s[/apps/root/PRO/root/lib][]g;"
Once this is done, perform a clean scons build and everything should work…famous last words :-p
There should be a ` character in front of echo. I could not figure out how to disable the code insertion character in the thread.
OK, I think I have fixed SConstruct to check this properly now (first checking to see if EVIO_LIBDIR/EVIO_INCDIR are defined, then if EVIO is defined, then if CODA is defined). In each case, it checks to see if the specific evio.h and libevio.* files are present. Here is the commit:
I just added these changes to the previous pull request that I already had open. Or at least I hope that I did.
Cheers, E.
Closed with commit 20cf746...89a98e4
When running scons on the cdaql1 computer, I had the problem that in podd it could not find the evio library. This is because in podd/SConstruct it checks to see if CODA env variable is defined. If CODA is defined then it assumes that the evio library and include files are there. On cdaql1, it is defined as /site/coda/2.6.2 but there are no evio library or header file in Linux/lib and Linux/include.
It seems that we need to add a check that the evio libraries and header files can be found rather than just check that the CODA variable is defined. I CODA evio not found then use the evio gotten from github. I do not think we can assume the same CODA directory structure everywhere.