Dhanya Thattil 05f657c106
Versioning (#568)
- removed getClientServerAPIVersion in server (not used)
- removed rxr side (clientversion compatibility check), removed enum as well as it is now done on the client side.
- versionAPI.h
   - GITBRANCH changed to RELEASE
   - dates for all API changed to "sem_version date". Scripts to compile servers modified for this. Empty "branch" name will end up with developer for sem_version.

- Version class with constructor taking in the long version (APILIB date). Other member functions including concise(to get sem_version for new releases and date for old releases), 
  
- bypassing initial tests, also now bypasses the client-rxr compatibility check (at rx_hostname command)

- previously, compatibility between client-det was ensuring both had the same detector API (eg. same APIJUNGFRAU)
   - Now, compatibility only checks APILIB (client side) and detector API(eg. APIJUNGFRAU) (detector side) have same major version. It only does backward compatibility test. Rest is upto user to ensure. 
   - If server is from an older release, it will compare dates like previous implementation (APIJUNGFRAU from both client and det)
 
- - previously, compatibility between client-rxr was ensuring both had the same APIRECEIVER
   - Now, compatibility only checks APILIB (client side) and APIRECEIVER (rxr side) have same major version. It only does backward compatibility test. Rest is upto user to ensure. 
   - If rxr is from an older release, it will compare dates like previous implementation (APIRECEIVER from both client and rxr)

- removed APIGUI, evalVersionVariables.sh, genVersionHeader.sh (not needed or not used)

- clientVersion, rxrversion and detectorserverversion all return strings and not integers (in hex) anymore. Depending if it has semantic versioning, it will print that or the date if it is too old.

- fixed in python (strings for versions)
- check_version function in detector server changed to "initial checks" as it only checks server-firmware compatibility and initial server checks. Client compatibilities are moved to client side.
- --version gives sem_version and date? Is date needed as well. The clientversion, detserverversion and rxrversion API gives only sem_version (no date)
- - formatting
2022-11-09 11:13:09 +01:00
2022-04-27 11:29:04 +02:00
2022-10-27 11:55:09 +02:00
2022-10-24 12:09:52 +02:00
2022-11-09 11:13:09 +01:00
2021-11-25 13:01:23 +01:00
2021-11-25 11:30:14 +01:00
2022-11-09 11:13:09 +01:00
2022-11-09 11:13:09 +01:00
2022-11-09 11:13:09 +01:00
2022-11-09 11:13:09 +01:00
2022-11-09 11:13:09 +01:00
2022-09-01 15:30:04 +02:00
2020-05-05 10:04:52 +02:00
2022-04-07 14:39:26 +02:00
2020-02-17 17:43:14 +01:00
2020-11-09 14:54:41 +01:00
2022-07-12 11:01:00 +02:00
2021-10-18 11:43:11 +02:00
2021-10-08 18:26:43 +02:00
2022-11-07 12:49:04 +01:00
2021-10-18 14:54:25 +02:00
2022-11-09 11:13:09 +01:00
2022-11-09 11:13:09 +01:00
2022-11-09 11:13:09 +01:00

Note

Please do not update to any xxxx.xx.xx.dev0 tags. They are not releases, but tags for internal usage. Use only releases with tags such as x.x.x or x.x.x-rcx.

Documentation

5.0.0 - Latest Release

Detailed documentation on the latest release can be found in the software wiki and on the official site.

Older Releases

Documentation is found in the package.

Binaries

Binaries for the slsDetectorPackage are available through conda.

#Add conda channels
conda config --add channels conda-forge
conda config --add channels slsdetectorgroup
conda config --set channel_priority strict

conda install slsdetlib   #only shared lib and command line
conda install slsdet      #python bindings (includes slsdetlib)
conda install slsdetgui   #gui (includes qt4)

#Install specific version
conda install slsdet=2020.03.02.dev0 #developer version from 3 March 2020

Source code

One can also obtain the source code from this repository and compile.

git clone https://github.com/slsdetectorgroup/slsDetectorPackage.git

Dependencies

Refer this page for dependencies.

Compilation

Compiling can be done in two ways. Either with the convenience script cmk.sh or directly with cmake for more control.

1. Compile using script cmk.sh

These are mainly aimed at those not familiar with using ccmake and cmake.

    The binaries are generated in slsDetectorPackage/build/bin directory.

    Usage: ./cmk.sh [-c] [-b] [-p] [e] [t] [r] [g] [s] [u] [i] [m] [n] [-h] [z] [-d <HDF5 directory>] [-l Install directory] [-k <CMake command>] [-j <Number of threads>]
    -[no option]: only make
    -c: Clean
    -b: Builds/Rebuilds CMake files normal mode
    -p: Builds/Rebuilds Python API
    -h: Builds/Rebuilds Cmake files with HDF5 package
    -d: HDF5 Custom Directory
    -k: CMake command
    -l: Install directory
    -t: Build/Rebuilds only text client
    -r: Build/Rebuilds only receiver
    -g: Build/Rebuilds only gui
    -s: Simulator
    -u: Chip Test Gui
    -j: Number of threads to compile through
    -e: Debug mode
    -i: Builds tests
    -m: Manuals
    -n: Manuals without compiling doxygen (only rst)
    -z: Moench zmq processor

    
    # get all options
    ./cmk.sh -?

    # new build  and compile in parallel:
    ./cmk.sh -bj5

2. Compile without script
Use cmake to create out-of-source builds, by creating a build folder parallel to source directory. This would create a debug build with address sanitizers.

    $ mkdir build
    $ cd build
    $ cmake ../slsDetectorPackage  -DCMAKE_BUILD_TYPE=Debug -DSLS_USE_SANITIZER=ON
    $ make -j12 #or whatever number of threads wanted

To install binaries using CMake

    git clone --recursive https://github.com/slsdetectorgroup/slsDetectorPackage.git
    mkdir build && cd build
    cmake ../slsDetectorPackage -DCMAKE_INSTALL_PREFIX=/your/install/path
    make -j12 #or whatever number of cores you are using to build
    make install

Support

dhanya.thattil@psi.ch
erik.frojdh@psi.ch
Description
Mirror of our github project
Readme 276 MiB
Languages
C++ 63.2%
C 25.2%
Python 8.2%
Shell 1.8%
CMake 1.3%
Other 0.3%