o2-qc-run-qc becomes o2-qc (#227)

* fix newline in new module's script

* o2-qc-run-qc becomes o2-qc

Author: Barthelemy

Framework/CMakeLists.txt

@@ -118,7 +118,7 @@ set(EXE_NAMES
     o2-qc-info-service
     o2-qc-info-service-dump
     o2-qc-run-producer
-    o2-qc-run-qc
+    o2-qc
     o2-qc-run-basic
     o2-qc-run-advanced
     o2-qc-run-readout
@@ -132,7 +132,7 @@ set(EXE_OLD_NAMES
     qcInfoService
     qcInfoServiceDump
     qcRunProducer
-    qcRunQC
+    o2-qc-run-qc
     qcRunBasic
     qcRunAdvanced
     qcRunReadout

Framework/src/runDataProducer.cxx

@@ -17,7 +17,7 @@
 /// This is an executable with a basic random data producer in Data Processing Layer. It does not serve a real purpose
 /// on its own, but it can be used as a data source for QC development. For example, one can do:
 /// \code{.sh}
-/// o2-qc-run-producer | o2-qc-run-qc --config json://${QUALITYCONTROL_ROOT}/etc/basic.json
+/// o2-qc-run-producer | o2-qc --config json://${QUALITYCONTROL_ROOT}/etc/basic.json
 /// \endcode
 ///
 /// If you have glfw installed, you should see a window with the workflow visualization and sub-windows for each Data

Framework/src/runQC.cxx

@@ -18,7 +18,7 @@
 /// topology which can provide data to Data Sampling and QC. This also means that cannot work on its own, as it would
 /// lack input data. A typical usage would be:
 /// \code{.sh}
-/// o2-qc-run-producer | o2-qc-run-qc --config json://${QUALITYCONTROL_ROOT}/etc/basic.json
+/// o2-qc-run-producer | o2-qc --config json://${QUALITYCONTROL_ROOT}/etc/basic.json
 /// \endcode
 /// Please refer to Framework/example-default.json and Framework/basic.json to see how to configure a QC topology.
 /// To generate only the local part of the topology (which would run on main processing servers) use the '--local' flag.

Framework/src/runReadout.cxx

@@ -17,7 +17,7 @@
 /// This is an executable showing how to connect to Readout as external data source. It consists only of a proxy,
 /// which can inject the Readout data into DPL. This workflow is intended to be merged with the QC workflow by doing:
 /// \code{.sh}
-/// o2-qc-run-readout | o2-qc-run-qc --config json://${QUALITYCONTROL_ROOT}/etc/readout.json
+/// o2-qc-run-readout | o2-qc --config json://${QUALITYCONTROL_ROOT}/etc/readout.json
 /// \endcode
 /// If you do not need to sample data, use the readout-no-sampling.json file instead.
 ///

doc/ModulesDevelopment.md

@@ -113,7 +113,7 @@ In case one needs to sample at a very high rate, or even monitor 100% of the dat
 }
 ```
 
-The file `basic-no-sampling.json` is provided as an example. To test it, you can run `o2-qc-run-qc` with that configuration file instead of `basic.json`.
+The file `basic-no-sampling.json` is provided as an example. To test it, you can run `o2-qc` with that configuration file instead of `basic.json`.
 
 ### Code Organization
 
@@ -182,7 +182,7 @@ Change the lines as indicated below :
 Now we can run it
 
 ```
-o2-qc-run-basic | o2-qc-run-qc --config json://${QUALITYCONTROL_ROOT}/etc/basic.json
+o2-qc-run-basic | o2-qc --config json://${QUALITYCONTROL_ROOT}/etc/basic.json
 ```
 
 You should see the QcTask at qcg-test.cern.ch with an object `Example` updating.

doc/QuickStart.md

@@ -68,9 +68,9 @@ Thanks to the Data Processing Layer (DPL, more details later) it is a single pro
 
 The presented example consists of one DPL workflow which has both the main processing and QC infrastructure declared inside. In the real case, we would usually prefer to attach the QC without modifying the original topology. It can be done by merging two (or more) workflows, as below:
 
-    o2-qc-run-producer | o2-qc-run-qc --config json://${QUALITYCONTROL_ROOT}/etc/basic.json
+    o2-qc-run-producer | o2-qc --config json://${QUALITYCONTROL_ROOT}/etc/basic.json
 
-This command uses two executables. The first one contains the _Producer, which represents a main data flow. The second executable generates the QC infrastructure based on given configuration file. These two workflows are joined together using the pipe | character. This example illustrates how to add QC to any DPL workflow by using `o2-qc-run-qc` and passing it a configuration file. 
+This command uses two executables. The first one contains the _Producer, which represents a main data flow. The second executable generates the QC infrastructure based on given configuration file. These two workflows are joined together using the pipe | character. This example illustrates how to add QC to any DPL workflow by using `o2-qc` and passing it a configuration file. 
 
 __Repository and GUI__
 
@@ -118,7 +118,7 @@ readout.exe file://$READOUT_ROOT/etc/readout.cfg
 
 Start the proxy, DS (DataSampling) and QC workflows :
 ```
-o2-qc-run-readout | o2-qc-run-qc --config json://${QUALITYCONTROL_ROOT}/etc/readout.json
+o2-qc-run-readout | o2-qc --config json://${QUALITYCONTROL_ROOT}/etc/readout.json
 ```
 
 The data sampling is configured to sample 1% of the data as the readout should run by default at full speed.
@@ -144,7 +144,7 @@ The payload received is a 2MB (configurable) data page made of CRU pages (8kB).
 __Configuration file__
 
 The configuration file is installed in `$QUALITYCONTROL_ROOT/etc`. Each time you rebuild the code, `$QUALITYCONTROL_ROOT/etc/readout.json` is overwritten by the file in the source directory (`~/alice/QualityControl/Framework/readout.json`).
-To avoid this behaviour and preserve the changes you do to the configuration, you can copy the file and specify the path to it with the parameter `--config` when launch `o2-qc-run-qc`.
+To avoid this behaviour and preserve the changes you do to the configuration, you can copy the file and specify the path to it with the parameter `--config` when launch `o2-qc`.
 
 To change the fraction of the data being monitored, change the option `fraction`.