Your remarks seem to suggest that the test for OS/compiler/library should be
pushed up to the Makefile (or similar script) level, so that the application
developer does not need to worry about testing for OS/compiler/library. But
isn't the Makefile author usually also the program author? Is it a big
difference between testing OS/compiler/library in a Makefile and testing it in
a source program ? Yes, testing it at the Makefile level does not require a
macro defining the OS. In your script, you test against the output of uname,
not a macro such as __sun or __SunOS_5_9; but before you write the script, you
need to know the output of uname for a particular OS. That seems to suggest
that the OS vendor needs to publicize that output ("Hey everyone, the output of
uname-s is SunOS on the Solaris OS."). And is it so different from my
suggestion that the OS vendor suggest a standardized preprocessor macro, such
as __sun, for everybody's use?
Another point is that whereas you define _XOPEN_SOURCE using the compiler -D
option, it is considered better to #define _XOPEN_SOURCE in the source program.
The GNU libc Manual
(http://www.gnu.org/software/libtool/manual/libc/Feature-Test-Macros.html)
suggests: "You should define these macros by using '#define' preprocessor
directives at the top of your source code files. ... You could also use the
-D option to GCC, but it's better if you make the source files indicate their
own meaning in a self-contained way."
If one defines _XOPEN_SOURCE in the source program, then one needs to test the
OS identification macro in the source program, as my examples show. What if
one gets rid of the '#if defined __sun', for instance, in my bind_thread()
example? Compiling it on Linux would generate errors complaining that
{sys/pset.h} cannot be found.
> SunOS-5.1[01] BEST_STD_FLAG=....
Is there SunOS-5.11? I am serious.
And what's the output of 'uname -s' and 'uname -r' on Open Solaris?
--
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
