From: Steven R. L. <sr...@ic...> - 2009-09-11 23:52:18
|
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> |