On Fri, Apr 13, 2007 at 06:13:30PM -0500, Spencer Janssen wrote:

On Fri, 13 Apr 2007 09:36:56 -0700 David Roundy wrote:

...

Also, the configure step in X11-extras doesn't seem to bother checking whether the xinerama library is present. Is this a bug in X11-extras, or in cabal? I certainly would hope that cabal would have the functionality to check for presence of libraries...

X11-extras currently assumes that xinerama is present. We should change this, probably by the 0.1 release of xmonad/X11-extras.

Any takers? ;)

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. I wonder if the Xinerama module should be a separate package anyway. What do you guys think about that? Jason Creighton

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...

...

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. 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 the upshot of this is, if we do autoconfig magic (which I think we probably should do), we can only export getScreenInfo and forget about providing a low-level interface to Xinerama. I do not think this is a major concern. The other functions are fairly useless: xineramaIsActive does what you'd expect, xineramaQueryExtension returns X11 extension numbers, which I think would only be useful for low-level X11 programming, and xineramaQueryVersion returns the major and minor version numbers of the Xinerama protocol being used. Again, I do not see these as major issues. Xmonad only uses getScreenInfo, and I don't know of anybody else that even uses the Xinerama wrapper. If, in the future, somebody comes up with a valid use case for them, we can cross that bridge when we come to it. 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. Jason Creighton

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

On Sat, Apr 14, 2007 at 09:52:33AM -0700, David Roundy wrote: [snip...defering to Stefan on cabal issues]

...

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...)

Oh, that's a great idea. I should have thought of that. :) If we have xineramaIsActive return False, and all the others return Nothing, the interface will act just like Xinerama's there, but disabled. (As is the case when you only have one screen.) So I'll do it that way. I don't know whether they are "really useless" or not, but with your idea it's very easy to make them available. So I don't see any reason not to export them. I don't want to be in the position of telling people "sorry, you can't call that function; I didn't think you would need it." Jason Creighton

droundy:

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).

Well, it does via ./configure scripts.

...

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

Right, which it doesn't. This is what the cabal configurations stuff is proposed to solve.

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.

Ok. This is possible. We use a ./configure script, emit a warning, set a cpp define in config.h, then compile with or without xinerama. -- Don