>I believe that we are using the native compilers since
>the resulting executables are supposed to be faster than
>by using GNU products.
Certainly using native compilers does make maintenance more difficult.
Do you
know for sure that native compilers are indeed faster? Or is this pure
speculation. And how much faster are they? 1%? 100%? And is our
problem
at this point really CPU performance? My understanding is that at
this point to produce any physics or detector plots, data is
reprocessed through RECSIS anyway, ie, the tracking is *redone* every
time,
so CPU performance is really an issue? Software maintenance on a
variety
of platforms is the more pressing issue at this juncture.
And anyway, aren't we ultimately going to be doing production processing
on Pentium/Linux machines, where we will be forced to gcc anyway?
Sorry, your argument doesn't make too much sense to me.
And would it be possible for you to reply to the list, so we can have a
*full*
dialog with *all* interested and informed parties. I am sure I am not
the
only one interested in your opinions. If this is not the correct forum
to discuss purely software design issues, then lets create one that is.
>All the packages developed for RECSIS are working fine
>with these compilers, on each of the required platforms.
>
>Our need to compile some code with gcc has arisen since
>the adoption of the map manager package.
>
>As the librarian, I believe that it is the duty of the
>proponents/creators of the map manager package to ensure
>that this code is portable to other platforms and native
>compilers, and not that of all the other developers to align
>themselves on the one compiler, namely gcc.
>
>So I would favor the solution of keeping things as they are,
>and ask Joe Manak, the keeper of mapmanager, to insure that
>his 'ward' conforms with the rest of the analysis packages.
>
>Regards
>
>Luc
--
Regards,
D. P. Weygand
Physics Department
Brookhaven National Laboratory (soon to be JLAB)
(516) 344-7231
weygand@cebaf.gov
http://www.phy.bnl.gov/~weygand/weygand.html