Let me put some water over the fire:
If you check the mailing list archives, there have *always* been
problems with portability. From day one, there have been compilers
that have had different problems, and this will continue to be so
for a long time.
Get over it.
Therefore, it's not fair to suggest that Lgb is on a personal
crusade to suddenly limit LyX to a few selected top-of-the-line
compilers. He has never done that.
Yes, he is interested in cleaning up the code, and in that context,
it's only reasonable to try to it in a modern way. But he has always
be moderate in the requirements.
It was Allan and I that suggested we should try out XTL. We did,
and Angus helped us a great deal to improve portability. But in the
end, we learned that it just required too much on the compiler.
So, the merged GUI independence code does not require XTL.
But the point is that we could not have know about this beforehand.
This process is only natural: We try to do it the best way, and
then deal with the problems. If we can't deal with the problems,
we back out.
But just because there is a risk that we have to back out, we
shouldn't be afraid to try new things.
I remember three years ago. The discussion was the same: Should
we support gcc 2.6.x? At that point, we were arguing whether
we should use "bool" and "const".
Was it then a mistake to begin to use bool and const? No way!
Is it a mistake to try to use STL now? No way!
Is it a mistake to try to use namespaces now? No way!
Is it a mistake to try to use sstream now? No way!
As long as you are willing to accept that the experiment turned
out negative, there is no harm done.
Come on, people. LyX does *not* at all require a state-of-the-art
compiler:
We require *basic* STL support. Most compilers have that, but we
are even willing to circumvent problems with string.clear().
We are struggling a bit with strstream and sstream, and it seems
that we might have to back out a bit here.
But there is nothing new under the sun: Some work is done. It
is tested by people with different compilers, and it turns out
that there are problems to be fixed.
We are *slowly* following progress. But you can not expect
you to know what new features will work on most C++ compilers
beforehand. There is only one way: Try, and then fix the problems.
If you can't fix the problems, or it becomes too ugly, back out
and do it another way.
That's the way we have always been doing, and that's the way
we should continue doing things.
Of course, it's a bitch to be the one with the oldest compiler,
because then you have to do most of the fixing. For this reason
alone, we have the Fridays and then you can bitch about it,
and afterwards feel better because you helped the project.
As you say: It's a community effort, and it has to stay this way.
But we should not hold each other back hand in hand.
We should go forward hand in hand.
Greets,
Asger
