This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: [Lsb-wg] opposition to LSB 2.0 rc1
- From: "Wichmann, Mats D" <mats dot d dot wichmann at intel dot com>
- To: "Alan Cox" <alan at lxorguk dot ukuu dot org dot uk>
- Cc: "Benjamin Kosnik" <bkoz at redhat dot com>, <gcc at gcc dot gnu dot org>, <libstdc++ at gcc dot gnu dot org>, <anderson at freestandards dot org>, <lsb-wg at freestandards dot org>
- Date: Thu, 29 Jul 2004 18:31:02 -0700
- Subject: RE: [Lsb-wg] opposition to LSB 2.0 rc1
>Rewording the C++ part as a migration reference of some sort might work
>as I know vendors really don't want to lose it. I know it
>won't make the vendor who voted against any happier but at least making
>it clear that the C++ stuff is broken, we know its broken and it'll be
>obsoleted ASAP would set the right expectations all around.
Open to suggestions on how C++ could be delivered in a way that
makes it both not seem like a permanent solution and yet seem
usable to people who want to start developing C++ LSB applications.
In other words, not such a strong statement that it looks like
we're locked in forever, but not such a weak statement that
nobody bothers to use it because they can't depend on it on
an LSB 2.0 system.
We haven't come up with a plan that makes that look right -
but that may not mean it's impossible to do so.
This issue highlights why the LSB stays out of package/version
level decisions and focuses on functional descriptions, despite
how much slower that makes evolving the LSB. package/version
means you have to get everybody to sync up at the same time,
and it's basically impossible. Unfortunately the implementation
of C++ seems to make it impossible to stay out of those waters.