Re: [Stlport-devel] patches for HP-UX/aCC

[Petr O. <pt...@is...>]

On Friday 11 August 2006 01:40, Boris Gubenko wrote:
> Petr Ovtchenkov wrote:
>=20
> > As I understand Boris Gubenko, he has C compiler, but by some reasons
> > (I not understand ones), he don't want to use it.
> >
>=20
> I think, the question is an inverse one: why would one want to use
> two compilers when a single one is fine?

Ugu. Banner across the screen: "You still writing some programs on C? Then =
we go to you!".

>=20
> But I'll give you specific reasons:
>=20
> Adding HP-UX C to STLport build will, at the very minimum, require
> registering it as a known compiler. In _system.h, I believe. See my
> 2006-08-07 19:51 update to 1536225.=20

Really no. Gcc is named as 'c++' for C++ or 'gcc'  for C all the way.
SunPro's compiler use CC/cc; VCs differentiate sources by extention
(and use /TC or /TP too, if required).
The words 'registering' not correct here at all.

> It will also require some trickery in STLport wchar.h, see the update.

May be. Then do this trick, and make request to other HP team about problem.
This really looks as long-term bug in HP's headers: wchar not usable by C (=
right?).

>=20
> Now, since HP-UX C compiler does not define __HP_aCC macro, some
> conditionalizing for HP-UX in STLport headers may not be correct in
> compilation with C.

But __hpux present. And in _system.h I say: "detect and use settings for OE=
 first,
then detect and use compiler-specific setting".
If STLport headers (that may be used by C compiler) has problems, then chec=
k ones,
and say: 'hey, the header intended for C not pass through our C compiler: t=
his is a BUG'.

> I don't think, that it is a problem for current=20
> c_locale.c module, but it may become a problem down the road.

The problem is treating one language as another.=20

>=20
> Do they look like valid reasons to you? TO NOT DO SOMETHING WHICH IS
> UNNECESSARY IN THE FIRST PLACE?

The same question to you: WHY YOU WANT TO KILL C? Ask kernel team, why
ones compile HP-UX kernel by C compiler, instead of beautiful aCC that has =
__HP_aCC macro?

[without joke: aCC is indeed beautiful C++ compiler]

=46rom you activity I begin to suspect that HP forget about C language at a=
ll:
<cite>
> why would one want to use two compilers when a single one is fine?
</cite>

>=20
> > Boris's suggestion boil down to "while you wrote c_locale.c on C,
> > let's rewrite one on C++".
>=20
> How you could reach this conclusion is a mystery to me, but if this
> is your understanding, then, I'm afraid, there is nothing I can do
> about it.

You say. Reread you posts to 1536225.  Reread you mails:

<cite>
> why would one want to use two compilers when a single one is fine?
</cite>
[note: aCC has no C mode, and treat sources strongly as C++ in any case]
Looks like I correctly understand you.

   - ptr