<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Thu, 2010-09-02 at 13:03 -0700, Alan Coopersmith wrote: <BLOCKQUOTE TYPE=CITE> <TT>> Not sure this is progress.  Generally people want to move away from</TT> <TT>> #ifdef's and move to putting checks in the configure script instead of</TT> <TT>> the other way around.</TT> </BLOCKQUOTE> Somehow I got the opposite impression, but I cannot pin point how exactly. In this case, the platform check was incomplete/incorrect, so that helps in favor of using the compiler which is supposed to know this stuff better than anybody else. I also considered this platform check "duplicate code". The resource file in config already go through the pain of using the preprocessor, so why reinvent the wheel again. That's what tipped the balance in favor of ifdef. A small improvement would be to use CSRG_BASED as it encapsulates the definition of BSD-like systems. I did not think it was appropriate to include Xosdefs.h in there. There is also another definition of CSRG_BASED in the server. With either method, if a new distro comes along, an update is required. I also have this bug report in mind (<A HREF="https://bugs.freedesktop.org/show_bug.cgi?id=6305)">https://bugs.freedesktop.org/show_bug.cgi?id=6305)</A> which does not like either method. I try to find a feature check when possible. <BLOCKQUOTE TYPE=CITE> <TT>Ideally we'd figure out some way to test for -m support, instead of having</TT> <TT>to keep track of the set of uname values or preprocessor defines that</TT> <TT>currently represent OS'es with a BSD-like userland (while new BSD distros</TT> <TT>don't spring up as often as new Linux distros, it is still a pain every</TT> <TT>few years to go find all the places to add "|| dragonfly" or whatever the</TT> <TT>next new one will be, and the hybrids like GNU/kFreeBSD confuse things</TT> <TT>even more).</TT> <TT>Unfortunately, I can't think of a good way to test su functionality in</TT> <TT>a configure script.   I wonder if it would be better to replace use of</TT> <TT>su in the xdm-config with code to setuid before running the *.willing</TT> <TT>script, to a userid specified in a new option in the xdm-config.</TT> </BLOCKQUOTE> </BODY> </HTML>