make package around hexanode lib?

[davidslac]

A bug in SConsTools: https://jira.slac.stanford.edu/browse/PSRT-168

is breaking the RPM builds (search for " error" in below):

http://pswww.slac.stanford.edu/buildbot/builders/nightly-build-rhel7/builds/531/steps/build-opt-all/logs/stdio

We won't be able to build a new psana release until we get it in conda properly.

Right now it is installed at

/reg/common/package/hexanodelib/0.0.1/x86_64-centos7-gcc485

among the files

/reg/common/package/hexanodelib/0.0.1/x86_64-centos7-gcc485 $ ls -1
calibration_table.txt   # this is part of the example sort.cpp below, it reads this file
compile_x64.txt   # shows how we'll complie, g++ -o sort -m64  -Wall -O3 sort.cpp libResort64c_x64.a
                            # we don't need the -m64 here, its default
compile_x86.txt
libResort64c_x64.a                 # This looks like all we get for linux, a static lib
libResort64c_x86.a                  # wrong arch
resort64c.h                               # we'll put this at $CONDA_PREFIX/include/hexanodelib/resort64ch.h

resort64c_VS2010_x64.dll           # looks like all of this if for windows, visual studio?
resort64c_VS2010_x64.lib              
resort64c_VS2010_x86.dll
resort64c_VS2010_x86.lib

sort.cpp                                          # example

sort.sln                             # visual studio project files
sort.vcxproj
sort.vcxproj.filters
sort.vcxproj.user

sort_non-LMF_from_1_detector.zip
sorter.txt                                      # example config file for sort.cpp example

So we'll just take

libResort64c_x64.a -> $CONDA_PREFIX/lib 
resort64c.h              -> $CONDA_PREFIX/include/hexanodelib/resort64c.h

then we'll have to make a conda proxy package around it, like https://github.com/lcls-psana/hdf5/blob/conda/SConscript

and code will call via

or should the package be called hexanode? not hexanodelib

[msdubrovin]

David, I would prefer pckage name hexanode.

[davidslac]

I think we will have to make psana-conda dependent on this new hexanode package. We will have to put hexanode on our anaconda lcls-rhel7 channel.

[davidslac]

I'm only going to install it in the rhel7 conda, since it is only compiled under centos7. Hopefully we will get rid of rhel5/rhel6, but if users will need to run from shared memory on rhel5, someone should see if these binaries work there.

[msdubrovin]

It is fine with me. The only thing which I need is an access to this library from regular software configuration.

[davidslac]

Can you check in any local changes and tell me the name of the package that is linking against hexanode? I may need to update it against the new location, I just need to make sure it builds, just modify the SConscript, and possibly how you #include the header file

[davidslac]

We can't have your package called hexanode, and the proxy package called hexanode, this will have to wait until we meet.

[msdubrovin]

Today I work from home until 1:30pm and waiting for delivery of some stuff. Will be in the office after 2pm.

[davidslac]

@msdubrovin, I've checked in a change to your hexanode, and created a proxy package called hexanode_proxy.

The names here are difficult, I'm going to go with:

Our code:

• hexanode: Mikhail's wrapper around the binary distribution
• hexanode_ext: the name of a shared object library in Mikhail's code, for the Python extension, I think though, it would be better to go with _hexanode, that is the common practice, than I could use hexanode_ext for external
• hexanode_proxy a wrapper SConscript that will bring the distribution from roentdek into our rpm installation. We will then do #include/hexanode_proxy/resort64c.h" to link in
• hexanode_proxy the name of a proper conda package that will simply install the header file and library. It will live in the external channel
• hexanode_proxy on the conda branch, their is no need for a SConscript, we will let users expliciltly specify the library (like Mikhail's hexanode does)

Note, right now, my conda based SConscript function, I think, only looks for shared object libraries, this package just has a static. So we're not trying to automatically link it in for users.

[davidslac]

added hexanode-proxy 0.0.1 (from our local channels) to tha ana-1.2.0 environments