[csw-maintainers] #ifdef's for solaris versions

[Maciej (Matchek) Bliziński]

Hi Riccardo,

2013/9/7 Riccardo Mottola <rmottola at opencsw.org>:
> while a bit off-topic, since I am not speaking of software currently
> packaged, I bet you experienced this in the past while porting. I also hope
> GNUstep software will get into the packages sooner or later!
>
> Are there reliable #ifdef's for identifying solaris? and then, in case, its
> versions? I need certain  workaround for solaris and, furthermore some are
> needed only for solaris 8/9, but no longer in 10+. (I'm struggling with the
> missing stdint.h and the incomplete inttypes.h)
>
> Ideally something like this:
>
> #if solaris
> #if Solaris=8
> xxx
> #else
> #endif
>
> On Mac, extremely convenient macros are provided where I can check for each
> evrsion, including doing stuff like "<10.4."... but I did not find
> equivalent. Since these these patches would go directly in upstream, I need
> them no to impact anything else!

I found a recently written book about autotools. It didn't cover this
specific topic (library header files varying with ./configure time
test results), but I found out that the author sits no the same floor,
so came over and had a little chat.

The summary of the conversation is this:

- I confirmed that you should not depend on platform-dependent
defines, but test for features or behavior in the ./configure script
- if you're installing header files for a library, you should not
install (renamed or not renamed) config.h because it contains defines
such as package name and version, which then mess with the same
defines in the software you're compiling later (and including the
installed library's config.h)
- you can tweak the installed foo-config.h to remove/undef the
conflicting defines, but it's ugly
- since you can build on Solaris 9 and install on Solaris 10, the
installed foo-config.h will be probably broken; you need to build
separate on 9 and 10

...and last but not least:

- the library headers define the API of your library, right? then why
does the API of your library depend on the operating system? if you're
using types with varying size and you're hardcoding them in config.h,
switch to types with known/explicit sizes, and your library's API will
become better.

Going back to your original question, could you post a specific
example of a 9/10 difference? We can then look how to best handle this
example, and we'll potentially all learn something from it.

Maciej

[1] https://www.flameeyes.eu/autotools-mythbuster/