On Sat, Sep 27, 2008 at 9:23 AM, Ming Kin Lai <[EMAIL PROTECTED]> wrote:
> 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.
If you are going to support more than 3-4 variations of OSs I'd
suggest that you make use of autoconf. Manually playing with defines
not based on functionality quickly becomes a maintenance nightmare.
There is no need to use anything else from the GNU autobuild toolset.
automake just lays another indirection between you and the Makefile
that is mostly frustrating if you already know how to make Makefiles.
libtool is harmful to portability and is a pain in the ass to debug,
but might save you some work if you are just interested to compile on
the common modern Unix-like OSs.
>> 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?
% uname -s;uname -r
SunOS
5.11
% uname -a
SunOS bhelliom 5.11 snv_81 i86pc i386 i86pc
_______________________________________________
opensolaris-discuss mailing list
[email protected]
