At the moment this is done in the simple way that qmake is called from the configure script.
Since there is not really a straightforward way to look for Qt installations at certain paths,
the automatic determination of the available Qt version is only done through pkg-config.
In case Qt is found at non-standard installation paths, one can either use the configure options
"--with-qt3" or "--with-qt4" to specify the Qt directory or alternatively set the variable
PKG_CONFIG_PATH to some value like
/usr/lib/pkgconfig:/usr/local/lib/pkgconfig:$ROOTSYS/lib/pkgconfig:/opt/qtsdk-2010.02/qt/lib/pkgconfig
During the installation only one editor---either musredit or musrgui---is built and installed.
musredit/Qt4 is generally preferred over musrgui/Qt3.
The only way to install musrgui when also a sufficent Qt4 installation is present is to specify solely
the "--with-qt3" option on the configure level. If additionally the "--with-qt4" option is given, only
musredit will be installed.
Both editors still can be installed as previously---this step is merely to make the installation more
convenient for less-experienced users (hopefully).
A workaround has been implemented where it is not tried any more to "directly
parse the file" but rather the file is read into a memory buffer which then
is parsed.
For further information, see MUSR-122.
* Fixed a linking problem when only shared libraries are built on Cygwin
(introduced with the split-off of libPUserFcnBase).
In the RUN block data file names can now be given in the following way:
- without extension (default and only possible way up to now)
- with (completely) lower-case extension (e.g. .nxs)
- with (completely) upper-case extension (e.g. .NXS)
In any case, the file that is looked for can have both a lower-case or an upper-case extension.
It should now be possible to build a static version of musrfit and shared libraries for the user functions.
This is needed on systems which do not support linking static libraries to shared ones (like Cygwin).
These changes still need to be tested on Cygwin, especially with user functions implementing the "global interface".
The default (if no option is given) is now that only for newly generated or empty files the respective header will be written.
If data is appended to an existing file, it is assumed that the header also is present already!
In this case only the new data blocks are appended directly after to existing ones.
[Most probably this behavior is broken if used in a native Windows environment, however, this is not the only problem there...]
The previous option "noheader" is preserved.
It suppresses the output of the header in any case.
If new data are appended to an existing output file this is done at the end of the file---just as before!
A new option "header" has been introduced.
If this is given, the output of the header is forced---no matter if a file (probably with header) existed before or not.
Also in this case all new data (and the header) are appended at the end of the output file if it existed already.
In case both options are given, the default behavior is activated.
Non-existing msr-files in the specified list of runs are now ignored as far as possible!
Still a warning for each non-existing file will be issued!
Before, encountering such a file led to the termination of the program.
Also the writing of the empty lines at the end of the data-output-file should be fixed now in this case.
It is needed to get a "correct db-file".
Before, when the program has been aborted before the last run was processed, these empty lines had not been appended to the file.
