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

[Steven R. L. <sr...@ic...>]

Markus,
  Improving this would be a great idea (A side note: It would be good to 
be familiar with the changes in #3319 as far as where a couple of things 
are.)

One thing we might consider is to split platform.h into three files:

1. a static file (pposix.h ?) containing as many things as we can 
determine by #ifdef as possible, possibly including stanzas for lots o' 
platforms.

2. a file, initially (in SVN) empty ( 'platform.h'? ) containing only 
/those things which autoconf couldn't determine by #ifdef -/ i.e., if it 
couldn't find BYTE_ORDER in the #defines, it would add U_IS_BIG_ENDIAN here.

3. a file, initially (in SVN) empty ('user_config.h'?) containing user 
preference things.   --disable-rename could go here, as could any 
uconfig style defines.


Our goal of course would be to get #2 as small as possible, and empty on 
as many platforms as possible.

Also, #2/#3 could live in separate include directories, so that you can 
switch them in and out:

    $(CC)   -I/usr/include -I/usr/share/icu/include 
-I/usr/share/icu/$(PLATFORM)/include

   ( so that /usr/share/icu/i386-apple-darwin9.8.0/unicode/platform.h 
contains a small number of platform specific things )


Simplifying idea:
   autoconf could detect that the platform is "one of the ones we know 
works™" and just skip creating a special platform.h. Perhaps a suitable 
compiled or even compiled-executed test case could build with just the 
static file in #1, and if it builds, then you just skip all of the 
detection cases.  If it fails, continue as usual.

Again, great ideas.

Steven


Markus Scherer wrote:
> 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 <http://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.
>           o 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 <http://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
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> icu-design mailing list
> icu...@li...
> To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design


-- 
Steven R. Loomis  sr...@ic...
Technical Lead, ICU for C/C++   <http://icu-project.org>
IBM San José Globalization Center of Competency
<http://ibm.com/software/globalization>