RE: KAI C++ Linux patch

[Yves A. <yv...@re...>]

> Ok, I see your point about what the intended usage for
> ICU is. It seems that you envision that each
> application that uses ICU will be very tightly bound
> to it, and that the value of dynamic linking should
> only be considered within the scope of the
> application. That's reasonable and I'll happily use
> ICU in that way and just statically link to it.
> However, if that's all true, then there really is no
> value in bundling ICU with a Linux distribution, since
> it potentially could only serve such a tiny fragment
> of users, namely those users that have been left
> flapping in the wind by their application vendors with
> regard to ICU configuration and compiler choice.

Hey, as the packager of ICU for Debian GNU/Linux, I disagree with this
statically linked view :-) I think that whhat George was saying is that if
your application *absolutely needs to be certain that it has access to such
and such features of ICU* it may want to statically link against it. But see
my previous email about different C++ compilers.

> 1) The mh-linux file is included and it contains
> gcc-specific flags and settings. We should make
> configure include mh-kcc instead.

Can you make mh-kcc a mh-linux-kcc (see how below) and email it to me if you
still have problems? I'll get an evaluation version of KAI C++ and play with
it then. No guarantees.

> 2) The CFLAGS and CXXFLAGS variables in all the make
> files are wrong. They should be set to the values that
> I used in my original mh-kcc file.

CFLAGS and CXXFLAGS are typically set during the configure run, not
hardcoded in Makefiles. If KCC needs specific flags, there are a number of
options:

- Rename your mh-kcc to mh-linux-kcc and apply the following patch, run
autoconf, and see if everything works. If you still need specific options
for the compiler, do not change CFLAGS or CXXFLAGS but change the
definitions of COMPILE.c, COMPILE.cc, LINK.c, LINK.cc, SHLIB.c, SHLIB.cc.
See how that was done for the config/mh-*-* for examples.

- Contribute specific support for KCC to the Autoconf team, if that is
really what is needed. I doubt it (Autoconf checks for very common flags).

- Always run CFLAGS=what-makes-sense CXXFLAGS=what-makes-sense ./configure.
This is how people build things, for example: CFLAGS=-O2 CXXFLAGS-O2
INSTALL_PROGRAM=/usr/bin/install ./configure is how I configure the ICU
build for the Debian packages, Debian policy requiring -O2. But typically,
this is for user-specific flags, not compiler-sepecific flags, so
mh-linux-kcc is the right longer-term solution.

- Change runConfigureICU to accept for example a LinuxRedHatKCC platform
that will set the appropriate flags. See runConfigureICU. Since
runConfigureICU is supposedly for official platforms only (is it?) that may
be hard.

It would be nice at some point to separate platforms and compilers in the
ICU configs. But its' not easy, so for now we live with some heavy
duplications between mh-platform and mh-platform-othercc.

Hope this helps,
YA

PS: and an idea to finish: it could be nice to call AC_PROG_CC(cc gcc all
the compilers we support) in configure.in so that people don't always have
to set the compiler. For kcc they'd still need to unless they only get this
on, say, Solaris..