Der neue Dienst "GitLab am KIT" ist unter gitlab.kit.edu erreichbar.

Skip to content
  • we7765's avatar
    [FIX][REVERT] (ticket10): revert changeset:5527 · 862dca3b
    we7765 authored and we7765's avatar we7765 committed
    This is a legacy commit from before 2015-03-01.
    It may be incomplete as well as inconsistent.
    See COPYING.legacy and README.history for details.
    
    Problem: 
     libtfxx and libtsxx mutually depend on each other 
     this is undesired; in particular installation of libraries does not
     work frictionless; each of both, when being installed as the first of
     both, expects the other to be available already
    
    Cause:
     The cause for this problem is that both libraries use class definitions
     provided in header files of the other library.
    
    Changes:
     With changeset:5527 I tried to solve the problem by making libtsxx
     independent of libtfxx, which worked fine for libtsxx. It was necessary
     to reimplement class templates like Handle and RangeList formerly
     obtained from libtfxx in libtsxx. However, it turned out, that this
     rendered libtfxx unusable. The code in libtfxx, which uses code from
     libtsxx passes objects of type RangeList (in namespace tfxx) to the
     classes obtained from libtsxx. They however expect objects of type
     RangeList (in namespace tsxx).
    
     I had to revert this changeset in order to keep the code operational.
    
    Proposed solution:
     The problem is caused by the sets of time series file input/output
     classes being implemented as well in libtsxx and libtfxx. To
     disentangle both libraries I will move the time series file
     input/output to a separated library which then depends on both libtfsxx
     and libtfxx.
    
     The file i/o code from libtsxx is pre-libdatrwxx and for this reason
     out-dated and should be replaced in the long run. 
     The file i/o code from libtfxx is very elaborate and confusing and only
     used by stuploxx and should be refactored in the long run.
     The new library might therefor be an intermediate solution.
    
    Further development takes place in git repositories.
    Results will be presented here, once implemented and tested.
    
    
    SVN Path:     http://gpitrsvn.gpi.uni-karlsruhe.de/repos/TFSoftware/trunk
    SVN Revision: 5529
    SVN UUID:     67feda4a-a26e-11df-9d6e-31afc202ad0c
    862dca3b