Hello David, David Ashley wrote: > PLEASE DO NOT MAKE ANY CHANGES TO THESE DEFINES!!! > > These two defines are used by the configure script to determine if we > are compiling on the native architecture or not. Eliminating these > will reduce the capability to perform non-native compiles (cross > compiles) and linking. > In this step I was only talking about the C++ code, not the configure system. I did not check the use of these two (GENERIC_OS and GENERIC_OPSYS) in configure.
I just noticed that the value of these two (AIX, OPSYS_AIX, ...) is used in an inconsistent way in the C++ code. I intend to changed this to: #if defined(OPSYS_XXX) or #if !defined(OPSYS_XXX) Does anyone see a problem in this ? If so please give a short explanation and one sample.. Thanks very much. Bye Rainer > David Ashley > > On 08/06/2009 10:53 AM, Rainer Tammer wrote: >> Hello, >> >> Rick McGuire wrote: >> >>> The cleanup for #defines in the platform-specific code is far from >>> complete. A lot of this was inherited from the original IBM code, >>> which was not done very consistently. I'm not even sure how/where the >>> GENERIC_OS and GENERIC_OPSYS flags are used. This is certainly an >>> opportunity try to cleanup and normalize the usage. >>> >>> I think in terms of the different #defines, I think I'd prefer the >>> test to be done using the OPSYS_xxxx flags rather than the short form, >>> since there's smaller chance of accidental conflicts. >>> >>> However, using an OPSYS_xxxx flag should be the last option for >>> conditional compiles, and only for situations where the >>> conditionalized pieces apply to just a single platform. If something >>> applies to more than one system, then a CONFIG_ style flag set up by >>> the build environment is the preferred method of handling things. >>> >>> >>> >> OK, >> so I will try to clean it up to a consistent OPSYS_xxx version in the >> first step. >> In the second step we can try to reduce the amount of platform specific >> defines in favor of >> "configure defines". And maybe add some --with/--without configure switches. >> >>> Rick >>> >>> >>> >> Bye >> Rainer >> >> ------------------------------------------------------------------------------ >> 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 >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------ > > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ 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 _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
