Some portability issues

[Alan Coopersmith]

Kean Johnston wrote:
> The first issue seems to be a remnant of the old Imake world.
> Excluding files found in xorg-cf-files, a casual grep through
> the sources reveal 204 files that sill use SVR4 or SYSV as
> conditionals. That figure has a bit of noise in it, as my tree
> I am building includes xterm, which includes 13 files thus
> affected. The way I see it, there are two ways to fix this.
> The first would be to add a new standard XORG configure macro
> for system-specific defines. This may also make it easier to
> revive other platform ports. Something along the lines of
> XORG_PLATFORM_DEFINES as a macro, which can be added to the
> configure scripts, and which will add platform specific flags
> to CFLAGS. I can see problems with this approach though,
> unless we also provide some suitable .pc file that can produce
> those same flags for other applications to use, as they are needed
> for ALL compiles (because some of the files that contain these
> conditionals are in proto). I believe that the better approach
> would be to eradicate from all the sources such conditionals,
> or possibly set them in Xos.h or Xosdefs.h (which of the two
> would be the most appropriate?).

We should be getting rid of them and moving to autoconf functionality
tests instead, but haven't had time to eradicate all of them.   For
Solaris, we were saved from having to hunt down all the SVR4 #ifdefs
by this code that's been in Xosdefs.h for a couple of releases to
help non-Imake-configured programs build correctly with the X headers:

#ifdef sun
/* Imake configs define SVR4 on Solaris, but cc & gcc only define __SVR4
  * This check allows non-Imake configured programs to build correctly.
  */
#if defined(__SVR4) && !defined(SVR4)
#define SVR4 1
#endif

Someday I'd like to not need that, but haven't had enough hours to seek
and destroy all the #ifdef SVR4's (or to figure out why they are present
in some of the more obscure cases).

> A third issue I found when building the xserver was in the
> building of hw/xfree86/xf1bpp. Makefile.am uses a gcc-specific
> option (-include mfbmap.h). This is highly non-portable. Even
> if the decision was to only ever support gcc, at the very least
> that needs to change to -include $(srcdir)/mfbmap.h so that
> you can build outside of the source tree, but I don't think that
> GCC is the only supported compiler is it?

I thought we'd eradicated all those - I build with the Sun compilers
which also don't support -include, but just issues a warning, not a
fatal error when it's used.   Looking in the logs I see there are some
'cc: Warning: illegal option -nclude' messages I hadn't noticed before.
(Everything works fine on the machines I've tested on, though I don't
  think any of them have hardware whose driver uses xf1bpp.)

> I'm very close to getting all of these resolved (except for the
> first issue, which I would like guidance on) and would like to try
> and get patches in for the upcoming 7.2 release. Have I missed the
> boat on that? If so its no big deal, but it sure would be nice.

There's still time for build fixing patches, we've only really passed
the feature freeze so far I think.

-- 
	-Alan Coopersmith-           alan.coopersmith at sun.com
	 Sun Microsystems, Inc. - X Window System Engineering