On Sat, Apr 14, 2007 at 10:27:12AM -0600, Jason Creighton wrote:
On Sat, Apr 14, 2007 at 07:09:57AM -0700, David Roundy wrote:
On Fri, Apr 13, 2007 at 06:04:46PM -0600, Jason Creighton wrote:
I poked around the cabal docs for a bit, and I didn't see any obvious way to get cabal to check for the presence of certain headers. Also, if the headers weren't there, we couldn't really do anything anyway, other than fail with a friendlier error.
Argh! That seems crazy. How can cabal not have support for looking for libraries? It's not so hard to write, but this seems like it'd be critical--certainly it'll be critical if we're going to use cabal for darcs (as Eric is in the process of doing).
I Am Not A Cabal Expert. Please take what I say with a grain of salt. :)
But it does appear to me that, for right now anyway, the answer is "use autoconf or similar": http://www.haskell.org/ghc/docs/latest/html/Cabal/authors.html#system-depend...
Argh. I Am Less Of A Cabal Expert, but it seems like the whole point of using cabal at all is to do our build scripting in Haskell. (see below)
I wonder if the Xinerama module should be a separate package anyway. What do you guys think about that?
It could be, but then we'd still depend on the module, unless cabal supports optional package dependencies. I'd rather have a compile-time check whether xinerama is present, and preferably if it's not present then we should emit a warning (WARNING: compiling without xinerama support!!!) and compile an X11-extras with the same API, but which assumes just one screen. It doesn't seem like it should be that hard, and reducing the number of libraries required would definitely be a Good Thing. Most people don't actually have two monitors.
Yes, that could work. I'm working on doing this with a simple "configure" (just a plain shell script, no autoconf (yet?)) script. I'll let y'all know how it turns out.
Couldn't this be done in Haskell? It'd be a real shame if cabal doesn't have sufficient hooks to allow something like this to be written, and it seems like one ought to be able to write nice Haskell functions to do all the interesting autoconfish things. (And no, I don't mean to be a pain...)
This brings up another minor issue: Right now, Graphics.X11.Xinerama exports:
XineramaScreenInfo data structure xineramaIsActive :: Display -> IO Bool xineramaQueryExtension :: Display -> IO (Maybe (CInt, CInt)) xineramaQueryVersion :: Display -> IO (Maybe (CInt, CInt)) xineramaQueryScreens :: Display -> IO (Maybe [XineramaScreenInfo]) getScreenInfo :: Display -> IO [Rectangle]
The xinerama* functions are as direct as possible wrappers around their C equivalents. getScreenInfo is a helpful wrapper around xineramaQueryScreens that fakes out a single display when Xinerama is not active. (That's right: Even if the X11 servers supports Xienrama, if it's not currently being used, all the Xinerama-functions fail. Yay.) [...] So if nobody objects, I'm going to continue to work on autoconfig magic to make a "getScreenInfo" that works even in the face of non-existent Xinerama.
This sounds great to me. But I imagine that at least xineramaIsActive ought to be very easy to deal with in the absense of Xinerama (always return True, or False?). And the others also seem like you could stub them out in such a way that the behavior of a Xinerama-aware program will be the same for a single screen either with or without Xinerama support compiled in. And I guess just returning Nothing for the rest will also be consistent? Why not export all of these in either case? Then developers could code once, and their code would behave in the same way, regardless of whether the Xinerama library isn't present or Xinerama itself isn't being used, but we don't lose any of the exported power. (Unless these functions are really useless, in which case there's no need to bother...) -- David Roundy http://www.darcs.net