[Xmonad] how to install?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

David Roundy-2
Hi all,

I made a somewhat desultory attempt at compiling xmonad, and am sad to
admit that I've failed, mostly because I've never learned to use cabal.
Yes, I'm terribly old-fashioned and out-of-date...

In the X11-extras directory I run:

./Setup.lhs configure --prefix=/home/droundy
./Setup.lhs build
./Setup.lhs install

and install fails because of lack of permissions.  It seems that I could
instead use ./Setup.lhs copy, but then when I configure xmonad, cabal fails
to find X11-extras.

Any suggestions?

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...
--
David Roundy
http://www.darcs.net
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

Alec Berryman
David Roundy on 2007-04-13 09:36:56 -0700:

> In the X11-extras directory I run:
>
> ./Setup.lhs configure --prefix=/home/droundy
> ./Setup.lhs build
> ./Setup.lhs install
>
> and install fails because of lack of permissions.

It's trying to register the package for the entire system instead of
just for your user.  If you run configure with the --user flag, it will
register X11-extras with your local ghc-pkg database instead of the
system-wide one.

This is why the copy command succeeds but then xmonad can't find
X11-extras; X11-extras is in the right place, but ghc-pkg hasn't been
told that it's available.
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

Spencer Janssen-2
In reply to this post by David Roundy-2
On Fri, 13 Apr 2007 09:36:56 -0700
David Roundy <[hidden email]> 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? ;)


Cheers,
Spencer Janssen
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

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

> On Fri, 13 Apr 2007 09:36:56 -0700
> David Roundy <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

David Roundy-2
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 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.
--
David Roundy
http://www.darcs.net
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

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

> > 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
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

Alec Berryman
Jason Creighton on 2007-04-14 10:27:12 -0600:

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

That sounds like a good solution - it would be a pain to do autoconf
magic on each application using X11-extras to swap in/out Xinerama-aware
functions.
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

David Roundy-2
In reply to this post by 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-dependent

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
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

Stefan O'Rear
On Sat, Apr 14, 2007 at 09:52:33AM -0700, David Roundy wrote:
> 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)
> ...
> 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...)

The whole Setup.hs thing, including hooks, is considered by the Cabal
devs to have been a mistake.  Cabal is a deliberately minimalist
system, it is not intended to replace autoconf in the extremely tricky
business of finding C libraries.  OTOH, cabal handles the tricky
business of building Haskell programs in a simple and extensible way.
So they complement each other, and you're just asking for pain if you
try to have one subsume the other.

The Intended Way Forward is that people should never use hooks,
instead the .cabal file should handle all Haskell issues and
./configure should handle C issues.  This obviously will not work for
all programs (though I suspect it would work for darcs).  Programs it
doesn't work for should use something different, not complicate Cabal.

Stefan
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

Jason Creighton
In reply to this post by David Roundy-2
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
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

Stefan O'Rear
On Sat, Apr 14, 2007 at 11:47:25AM -0600, Jason Creighton wrote:
> On Sat, Apr 14, 2007 at 09:52:33AM -0700, David Roundy wrote:
>
> [snip...defering to Stefan on cabal issues]

I'm not a cabal dev either :) I was just explaining my
(mis?)understanding of what dons&dcoutts have told in #haskell.  So
don't take my words as gospel, please!

Stefan
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

Donald Bruce Stewart
In reply to this post by Jason Creighton
jcreigh:

> On Fri, Apr 13, 2007 at 06:13:30PM -0500, Spencer Janssen wrote:
> > On Fri, 13 Apr 2007 09:36:56 -0700
> > David Roundy <[hidden email]> 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.

Yeah, pretty sure cabal can't directly do this. Of course, cabal will
run any ./configure script we provide, which could happily check for
Xinerama, and then generate a config.h

> I wonder if the Xinerama module should be a separate package anyway.
> What do you guys think about that?

We could also have two cabal files.

-- Don
Reply | Threaded
Open this post in threaded view
|

[Xmonad] how to install?

Donald Bruce Stewart
In reply to this post by David Roundy-2
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