[icu-design] ICU4C: un-autoconf platform.h?

[Markus S. <mar...@gm...>]

Dear ICU team and users,

ICU has one header file whose final form is not in the source tree,
platform.h. It is autoconf-generated (from
platform.h.in<http://bugs.icu-project.org/trac/browser/icu/trunk/source/common/unicode/platform.h.in>)
for the platform and compiler.

This has helped with porting, but has been inconvenient for cross-compiling
and generally for using the same set of source files for multiple platforms.
(Some build systems want to do that. I remember a request from a few years
ago about building AIX 32-bit and 64-bit binaries from the same source
tree.)

I see that platform.h.in actually has a mix of two different kinds of
settings:

   - It has platform-specific settings, such as U_IS_BIG_ENDIAN. I would
   like to determine these via #ifdef if possible, so that we need not
   autoconf-generate any .h file for different platforms.
   - It has user-preference settings, such as U_DISABLE_RENAMING, which have
   nothing to do with platform differences. These are not driven by the usual
   configure-script logic but by command-line switches like --disable-renaming.
   We could keep these (and only these) autoconf'ed, or we could require users
   to set them by modifying the source file instead.
      - If only user-preference settings are autoconf'ed, then the resulting
      platform.h file could be used for all platforms, which would remove the
      inconveniences for cross-compiling.

How different are the autoconf-generated platform.h files from different
platforms? I expect that most platforms these days have namespace support,
32-bit int, std::string, etc.

Could we use one platform.h with some #ifdef switches for the things that
are actually different between platforms? This would not be completely new,
because platform.h.in already contains some #ifdef's, for example for
handling different z/OS (OS390) versions and MacOS X (Darwin) PPC vs. x86.

For platforms that are very different, we could use separate .h files, like
we do with pwin32.h and ppalmos.h.

Thoughts?

Sincerely,
markus