Re: Brat 2-5-3

From: Flemming Videbaek (videbaek@sgs1.hirg.bnl.gov)
Date: Tue Oct 01 2002 - 16:32:05 EDT

  • Next message: David Sandberg: "Installing brat."

    Just a few comment(s) since there are some decision to be made.
    
    
    -- minor comment
    >
    > > In BrDetectorParmasBase::ReadASCIIFile() the variable system_param_file
    > > was an Char_t[64] array which was a bitt to small to hold the entire
    > > path to the BrDetectorParameters.txt Changed it to Char_t[256].
    >
    > Why is it a Char_t array in the first place?  It should be a TString
    > or a std::string.
    
    Well maybe this is because this was a pretty old module - after all lost of
    brat stuff are from before
    stdc++ became a reasonable library to use, and I belive before TString was
    even in ROOT (though
    I am not sure on this). In any case there is no general man-power to go back
    over old rouitnes/modules
    but if one comes across some one can of course change this if deemed
    important.
    
    
    
    -- more substantial
    >
    > Recently I compiled BRAT 2.4.7 (as it is our current `pro' release of
    > BRAT) and discovered it didn't even compile!  <sarcasm>Now that's nice
    > isn't it? - out production BRAT doesn't compile!</sarcasm>.
    >
    
    Well I guess it must have compiled if it is installed ?! so what changed?
    a) One  reason for this is that only very few people use the afs
    directories- with
    version compiled with different version of gcc. So the issue here is to go
    agree to make gcc3.04
    (or higher ?) the default compiler. On rcf rcas this is achieved by the
    alternate definition of
    gcc3, and g++3 - for this to work across platfomr that picks up root (in
    particluar rootcint) from afs
    the local names for gcc3.04 has to be gcc3 too.
    
    > BTW, iff BRAT-2.4.7 is too old and BRAT 2.5.3 is more or less stable
    > (at least compiles!), then that should become our `production'
    > version.  As outlined elsewhere (numerous emails and I believe also in
    > `The Guide') this is accomplished by starting a new development cycle,
    > which is done by incrementing the minor version number and zeroing
    > the revision number.
    
    b) Well the guide is good - but is not God
    the other  reason before the summer was to keep the production version
    beacuse of the data to be generated for qm - not for higher principles.
    Since this is now over this should be changed, but requiresan agreement on
    this
    as well as the time and people do so.
    
    
    cheers
        Flemming
    



    This archive was generated by hypermail 2b30 : Tue Oct 01 2002 - 16:22:14 EDT