Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-06 Thread Duncan Coutts
On Tue, 2009-02-03 at 19:25 +, Andrew Coppin wrote:
 Don Stewart wrote:
  The platform is a set of blessed libraries and tools. The distros will
  still need to package that.
 
  To do that for Windows, we're still going to need a windows packaging
  team, along side Debian, Arch, Gentoo, Mac etc.

 
 Right, so, let me make sure I understand this...
 
 1. We sit down and pick a set of libraries that cover a useful range of 
 subject areas, that are mature and stable, and that work well with each 
 other. This is the Haskell Platform.
 
 2. For each OS, a team decides how best to deploy this set of libraries 
 on that specific OS.
 
 Is that the plan?

More or less, yes. In practise we expect there to be quite a bit of
overlap and communication between the OS teams.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-05 Thread Andrew Coppin

Don Stewart wrote:

The platform is a set of blessed libraries and tools. The distros will
still need to package that.

To do that for Windows, we're still going to need a windows packaging
team, along side Debian, Arch, Gentoo, Mac etc.
  


Right, so, let me make sure I understand this...

1. We sit down and pick a set of libraries that cover a useful range of 
subject areas, that are mature and stable, and that work well with each 
other. This is the Haskell Platform.


2. For each OS, a team decides how best to deploy this set of libraries 
on that specific OS.


Is that the plan?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-03 Thread Neil Mitchell
Hi

 GHC doesn't  bundle with cabal-install on any system.

 What is needed is not for the GHC team to be doing Windows platform
 packages, but for the Windows Haskell devs to build their own system, as
 happens on all the Unices.

 Take GHC's release, wrap it up with native installers, throw in useful
 libraries and executables like cabal. Done.

GHC already takes the GHC release, bundles it up with a native
installer, and then throws in useful executables like gcc. It just
stops one hop short of done. Windows is special, we already treat
Windows special, but currently its just short of useable.

Duncan: Saying cabal.exe isn't mature enough to go in 6.10 is a
perfect reason, but one that you never gave at the time. If it isn't
ready, then that's fine. But if thats the case, will it be in 6.12, or
will the standard Windows instructions involve hunting around
haskell.org for a prebuild Cabal.exe?

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


RE: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-03 Thread Sittampalam, Ganesh
Don Stewart wrote:
 ganesh.sittampalam:
 Don Stewart wrote:

 So, wind...@haskell.org anyone? Get the wiki going, get the set of
 tasks created.
 
 Isn't the Haskell Platform going to do all this? Shouldn't
 interested people just help out there? 
 
 
 The platform is a set of blessed libraries and tools. The distros
 will still need to package that. 
 
 To do that for Windows, we're still going to need a windows packaging
 team, along side Debian, Arch, Gentoo, Mac etc. 

http://www.haskell.org/haskellwiki/Haskell_Platform section 4
talks about making distributions.

So what should people be trying to do? Focus on (a) general
infrastructure
for packaging any Haskell library/binary on Windows (etc), or on (b) the
specific task of packaging the Haskell Platform?

If (b) then I don't think a whole new mailing list/wiki etc is
worthwhile.
(a) would obviously be nicer but is no doubt a much harder problem - I
guess
we'd want to start with Bamse and perhaps make use of the
nestedInstalls
feature somehow.

Ganesh


==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-03 Thread Duncan Coutts
On Tue, 2009-02-03 at 08:26 +, Neil Mitchell wrote:
 Hi
 
  GHC doesn't  bundle with cabal-install on any system.
 
  What is needed is not for the GHC team to be doing Windows platform
  packages, but for the Windows Haskell devs to build their own system, as
  happens on all the Unices.
 
  Take GHC's release, wrap it up with native installers, throw in useful
  libraries and executables like cabal. Done.
 
 GHC already takes the GHC release, bundles it up with a native
 installer, and then throws in useful executables like gcc. It just
 stops one hop short of done. Windows is special, we already treat
 Windows special, but currently its just short of useable.

Right, that's the job the platform will take on.

 Duncan: Saying cabal.exe isn't mature enough to go in 6.10 is a
 perfect reason, but one that you never gave at the time. If it isn't
 ready, then that's fine. But if thats the case, will it be in 6.12, or
 will the standard Windows instructions involve hunting around
 haskell.org for a prebuild Cabal.exe?

It'll be in the first platform release which will be well before ghc
6.12.

BTW, I think I've been missing your advice and cajoling about Windows
platforms. It's been rather quiet recently.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread Duncan Coutts
On Mon, 2009-02-02 at 13:49 +0900, Benjamin L.Russell wrote:
 On Sun, 01 Feb 2009 15:01:28 +, Duncan Coutts
 duncan.cou...@worc.ox.ac.uk wrote:
 
 On Sat, 2009-01-31 at 16:50 -0800, Don Stewart wrote:
 
  Windows people need to set up a wind...@haskell.org to sort out their
  packaging issues, like we have for debian, arch, gentoo, freebsd and
  other distros.
  
  Unless people take action to get things working well on their platform,
  it will be slow going.
 
 Actually instead of going off into another mailing list I would
 encourage them to volunteer on the cabal-devel mailing list to help out.
 There is lots we could do to improve the experience on Windows and half
 the problem is we do not have enough people working on it or testing
 things.
 
 That sounds like a great idea, but what specifically should Windows
 users do to help out?  If we try to install a package on Windows and
 encounter a bug that we can't figure out, would it be sufficient to
 subscribe at http://www.haskell.org/mailman/listinfo/cabal-devel and
 to submit a bug report to cabal-de...@haskell.org ?

So on cabal-devel we are concerned with bugs and missing features in
Cabal that make life hard for windows users. We cannot directly fix
individual packages, there are too many and that is the job of the
package maintainers. 

We are interested in solving the more systemic problems however. So for
example working out if we can replace many of the configure scripts:
http://hackage.haskell.org/trac/hackage/ticket/482

Or just improving the error message when we fail to run configure
http://hackage.haskell.org/trac/hackage/ticket/403

Or support in the cabal-install planner for non-Haskell dependencies (so
we can track dependencies on sh.exe or libs that are not available on
Windows.) The point is to make best use of the available information to
work out which packages have no hope of building on Windows.

We also have a collection of tickets that primarily affect Windows:
http://hackage.haskell.org/trac/hackage/query?status=newstatus=assignedstatus=reopenedplatform=Windowsorder=priority

many of these need help from windows users, either to decide what the
solution should be or to test the solution.

Having more Cabal volunteers who use Windows would be great. I've
recently been trying to solve some permissions problems on Windows which
is pretty hard without having proper access to a Windows system. There
are also some important tickets that are just sitting around waiting for
some policy decision to be made. The couple people who used to advise us
on these questions (like what default install locations should be etc)
have not had time recently so these things just sit around with no
decisions made.

So actually just having more Windows users subscribed to cabal-devel and
commenting on tickets would be very useful, even if you do not have much
time for hacking.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread Don Stewart
ndmitchell:
 Hi
 
  So actually just having more Windows users subscribed to cabal-devel and
  commenting on tickets would be very useful, even if you do not have much
  time for hacking.
 
 I believe that as soon as a Windows user starts doing that you'll
 start asking them for patches :-)
 
 There are a number of reasons that we have fewer Windows developers:
 
 * Some of it comes down to social reasons - for some reason it seems
 to be socially acceptable to belittle Windows (and Windows users) on
 the Haskell mailing lists and #haskell.
 
 * Some of it comes down to technical issues - for example not having
 cabal.exe bundled with GHC 6.10.1 on Windows was a massive mistake
 (although I've heard everyone argue against me, I've not yet heard a
 Windows person argue against me).
 
 * Part of it comes down to most developers not being Windows people.
 
 * A little is because Windows is a second class citizen even in the
 libraries, my OS is NOT mingw32 - mingw32 is not even an OS, its a
 badly typed expression! How would you like it if your OS was listed as
 Wine? Things like this tell me that Haskell isn't Windows friendly, at
 best its windows tolerant.
 
 * Things like Gtk2hs, which Windows users need building for them,
 don't release in sync with GHC, which makes it hard to use.
 
 * Windows machines don't usually have a C compiler, and have a very
 different environment - while the rest of the world is starting to
 standardise.
 
 I gave up on fighting the fight when people decided not to bundle
 cabal.exe with Windows - and now I'm too busy with my day job... Now
 I'd say Duncan is the most vocal and practical Windows developer, even
 overlooking the fact he doesn't run Windows.

GHC doesn't  bundle with cabal-install on any system.

What is needed is not for the GHC team to be doing Windows platform
packages, but for the Windows Haskell devs to build their own system, as
happens on all the Unices.

Take GHC's release, wrap it up with native installers, throw in useful
libraries and executables like cabal. Done.

It's not the GHC compiler team's job to build distro-specific bundles. 

So, wind...@haskell.org anyone? Get the wiki going, get the set of tasks
created.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread Don Stewart
jwlato:
 Duncan Coutts wrote:
 
  Some are trivial and should be done away with. For example the ones that
  just check if a C header / lib is present are unnecessary (and typically
  do not work correctly). The next point release of Cabal can do these
  checks automatically, eg:
 
 Configuring foo-1.0...
 cabal: Missing dependencies on foreign libraries:
 * Missing header file: foo.h
 * Missing C libraries: foo, bar, baz
 This problem can usually be solved by installing the system
 packages that provide these libraries (you may need the -dev
 versions). If the libraries are already installed but in a
 non-standard location then you can use the flags
 --extra-include-dirs= and --extra-lib-dirs= to specify where
 they are.
 
 Thank you!  Thank you!  Thank you!
 
 For those of us who want to write cross-platform (i.e. Windows)
 bindings to C libraries, this is great news.

It will be important now to report the lack of uses of these portability
tests back to the authors of packages.

A start would be to have hackage warn, I suppose.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread Neil Mitchell
Hi

 So actually just having more Windows users subscribed to cabal-devel and
 commenting on tickets would be very useful, even if you do not have much
 time for hacking.

I believe that as soon as a Windows user starts doing that you'll
start asking them for patches :-)

There are a number of reasons that we have fewer Windows developers:

* Some of it comes down to social reasons - for some reason it seems
to be socially acceptable to belittle Windows (and Windows users) on
the Haskell mailing lists and #haskell.

* Some of it comes down to technical issues - for example not having
cabal.exe bundled with GHC 6.10.1 on Windows was a massive mistake
(although I've heard everyone argue against me, I've not yet heard a
Windows person argue against me).

* Part of it comes down to most developers not being Windows people.

* A little is because Windows is a second class citizen even in the
libraries, my OS is NOT mingw32 - mingw32 is not even an OS, its a
badly typed expression! How would you like it if your OS was listed as
Wine? Things like this tell me that Haskell isn't Windows friendly, at
best its windows tolerant.

* Things like Gtk2hs, which Windows users need building for them,
don't release in sync with GHC, which makes it hard to use.

* Windows machines don't usually have a C compiler, and have a very
different environment - while the rest of the world is starting to
standardise.

I gave up on fighting the fight when people decided not to bundle
cabal.exe with Windows - and now I'm too busy with my day job... Now
I'd say Duncan is the most vocal and practical Windows developer, even
overlooking the fact he doesn't run Windows.

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


RE: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread Sittampalam, Ganesh
Don Stewart wrote:

 GHC doesn't  bundle with cabal-install on any system.
 
 What is needed is not for the GHC team to be doing Windows platform
 packages, but for the Windows Haskell devs to build their own system,
 as happens on all the Unices.  
 
 Take GHC's release, wrap it up with native installers, throw in
 useful libraries and executables like cabal. Done. 
 
 It's not the GHC compiler team's job to build distro-specific bundles.
 
 So, wind...@haskell.org anyone? Get the wiki going, get the set of
 tasks created. 

Isn't the Haskell Platform going to do all this? Shouldn't interested
people just help out there?

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread Marc Weber
On Mon, Feb 02, 2009 at 10:07:57AM +, Neil Mitchell wrote:
 Hi

The nix package manager (although beeing primarly a linux tool) can run
on cygwin as well (at least it did some time ago)..
I'd suggest trying that to package windows libraries. It dose generate
tag files for you automatically as well. At least it can build
dependencies such as C libraries and so on for you automatically as
well.

Unfortunately I don't have time to work on the windows port.

The cool thing about nix is: You can always switch back to the previous
generation if something breaks. It organizes the packages like a memory
management system. You only reference the target and the deps in between
will be build / removed automatically for you if they are no longer
used when running the nix garbage collector. There is another drawback:
It definitely only works on a ntfs partition. On the other hand it does
also support binary distributions and install software by clicking on
links.

In the end this is perfect for developping (IMHO) even if you have to
learn a lot at the beginning.

My major problem hindering my starting to work on this is that cygwin
doesn't run on Vista running in kvm/ qemu. sh.exe exits and that's
it.

So if you have a solution for that I'd consider resuming work on it

Sincerly
Marc Weber
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread Don Stewart
ganesh.sittampalam:
 Don Stewart wrote:
 
  GHC doesn't  bundle with cabal-install on any system.
  
  What is needed is not for the GHC team to be doing Windows platform
  packages, but for the Windows Haskell devs to build their own system,
  as happens on all the Unices.  
  
  Take GHC's release, wrap it up with native installers, throw in
  useful libraries and executables like cabal. Done. 
  
  It's not the GHC compiler team's job to build distro-specific bundles.
  
  So, wind...@haskell.org anyone? Get the wiki going, get the set of
  tasks created. 
 
 Isn't the Haskell Platform going to do all this? Shouldn't interested
 people just help out there?
 

The platform is a set of blessed libraries and tools. The distros will
still need to package that.

To do that for Windows, we're still going to need a windows packaging
team, along side Debian, Arch, Gentoo, Mac etc.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread John Goerzen
Neil Mitchell wrote:

 * Part of it comes down to most developers not being Windows people.

That certainly describes me.  I find the platform annoying and stressful
(all the worries about security).

But another issue is: it's proprietary and expensive.

The base OS isn't cheap, and doesn't even come with development tools.
While GHC and friends do run on Windows for free, if you are trying to
deal certain things (Windows GUIs, ODBC, etc.) it is difficult at best
without shelling out the really big bucks for the Microsoft development
environment.

Having said that, I agree that good Windows support is a worthwhile goal
for the community, and I very much appreciate patches and bug reports
from Windows users.  However, I am in somewhat of a difficult position
when it comes to turning the latter into actual patches.

Of course, MacOS X is also proprietary and expensive.  But it has at
least a bastardized POSIX core, and as such seems to never really need
much porting from my Linux development environment.  At least until Mac
users start demanding resource fork and finder info support.  ;-)

-- John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread Duncan Coutts
On Mon, 2009-02-02 at 10:07 +, Neil Mitchell wrote:

 * Some of it comes down to technical issues - for example not having
 cabal.exe bundled with GHC 6.10.1 on Windows was a massive mistake
 (although I've heard everyone argue against me, I've not yet heard a
 Windows person argue against me).

There are reasonable arguments both ways. Listening to some people it
would seem that cabal.exe is there to taunt people with the potential
for usable packaging and then to punish them with broken packages,
quirky dependency resolution and twisty inconsistent installed package
graphs.

There is a tension between getting it out there because it's useful, and
not putting out something that is going to frustrate and annoy new
users. With the current release that balance seems to be pretty fine. I
hope that the next release will make it look a little more mature.

For example look at how many people have been getting themselves into a
complete mess recently from using cabal upgrade. There is a whole new
world of exciting mess you can make when using easy automated tools with
no safety catches. These are not problems that emerged at first because
it was only developers who knew what they were doing who were using it
at first. Now that more and more people are using it we're discovering
these usability problems. I fear that if we'd gone any quicker that we'd
have been completely swamped with bug reports and users might write the
whole thing off. Given the available developer resources I don't see how
we could have done significantly better (except perhaps by releasing
even later).

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread Duncan Coutts
On Mon, 2009-02-02 at 10:07 +, Neil Mitchell wrote:
 Hi
 
  So actually just having more Windows users subscribed to cabal-devel and
  commenting on tickets would be very useful, even if you do not have much
  time for hacking.
 
 I believe that as soon as a Windows user starts doing that you'll
 start asking them for patches :-)

Actually I deliberately didn't say that. I would be happy even with some
people dispensing advise and testing things.

 There are a number of reasons that we have fewer Windows developers:
 
 * Some of it comes down to social reasons - for some reason it seems
 to be socially acceptable to belittle Windows (and Windows users) on
 the Haskell mailing lists and #haskell.

Yes plenty of it is social issues. Some of the perceptions in the other
direction is that Windows users tend to expect everything to work and
not be prepared to help. This may be what they're accustomed to but it
tends to rub open source programmers up the wrong way.

 * Some of it comes down to technical issues - for example not having
 cabal.exe bundled with GHC 6.10.1 on Windows was a massive mistake
 (although I've heard everyone argue against me, I've not yet heard a
 Windows person argue against me).

I think if it had been bundled with ghc-6.10 you'd have heard lots more
Windows people complaining.

 * Part of it comes down to most developers not being Windows people.
 
 * A little is because Windows is a second class citizen even in the
 libraries, my OS is NOT mingw32 - mingw32 is not even an OS, its a
 badly typed expression! How would you like it if your OS was listed as
 Wine? Things like this tell me that Haskell isn't Windows friendly, at
 best its windows tolerant.

Note that cabal/hackage does not classify it that way.

 * Things like Gtk2hs, which Windows users need building for them,
 don't release in sync with GHC, which makes it hard to use.

Hardly anything releases in sync with ghc and it's unrealistic to think
that it can or should. The special problem for gtk2hs is that it has to
be distributed as a binary so it's guaranteed not to work with new ghc
releases where as most other packages will still build from source.

Again this comes down to lack of developers and lack of access to
Windows hardware. If we had the infrastructure we'd have auto-builders
to make releases with new ghc releases. Perhaps that's something we can
get people to work on. More automation is good. Building all of hackage
on windows and reporting the results would be very useful to everyone.
Not once but continuously.

 * Windows machines don't usually have a C compiler, and have a very
 different environment - while the rest of the world is starting to
 standardise.
 
 I gave up on fighting the fight when people decided not to bundle
 cabal.exe with Windows - and now I'm too busy with my day job... Now

The more I think about it the more I think that we fortuitously made the
right decision not to bundle cabal-install with ghc-6.10. We didn't
decide to do it due to immaturity but in hindsight that would have been
an excellent reason. As I said before, I hope we'll be able to fix
enough of the things that it'll be ok for the first platform release.

 I'd say Duncan is the most vocal and practical Windows developer, even
 overlooking the fact he doesn't run Windows.

I'm going to obtain a license and set up a VM.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread Duncan Coutts
On Mon, 2009-02-02 at 13:22 +, John Lato wrote:
 Duncan Coutts wrote:
 
  Some are trivial and should be done away with. For example the ones that
  just check if a C header / lib is present are unnecessary (and typically
  do not work correctly). The next point release of Cabal can do these
  checks automatically, eg:
 
 Configuring foo-1.0...
 cabal: Missing dependencies on foreign libraries:
 * Missing header file: foo.h
 * Missing C libraries: foo, bar, baz
 This problem can usually be solved by installing the system
 packages that provide these libraries (you may need the -dev
 versions). If the libraries are already installed but in a
 non-standard location then you can use the flags
 --extra-include-dirs= and --extra-lib-dirs= to specify where
 they are.
 
 Thank you!  Thank you!  Thank you!

Gleb Alexeyev did the majority of the work on this one. I'm most
grateful to him for heeding my recent calls for more volunteers for
Cabal hacking.

 For those of us who want to write cross-platform (i.e. Windows)
 bindings to C libraries, this is great news.

Yes. The next step will be for the cabal-install dependency planner to
use this information and to complain at the planning stage rather than
failing once it starts to try to build things.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

2009-02-02 Thread Duncan Coutts
On Mon, 2009-02-02 at 08:29 -0800, Don Stewart wrote:
 jwlato:
  Duncan Coutts wrote:
  
   Some are trivial and should be done away with. For example the ones that
   just check if a C header / lib is present are unnecessary (and typically
   do not work correctly). The next point release of Cabal can do these
   checks automatically, eg:
  
  Configuring foo-1.0...
  cabal: Missing dependencies on foreign libraries:
  * Missing header file: foo.h
  * Missing C libraries: foo, bar, baz
  This problem can usually be solved by installing the system
  packages that provide these libraries (you may need the -dev
  versions). If the libraries are already installed but in a
  non-standard location then you can use the flags
  --extra-include-dirs= and --extra-lib-dirs= to specify where
  they are.
  
  Thank you!  Thank you!  Thank you!
  
  For those of us who want to write cross-platform (i.e. Windows)
  bindings to C libraries, this is great news.
 
 It will be important now to report the lack of uses of these portability
 tests back to the authors of packages.

Note that to get the above checks authors don't have to do anything
except list the C libs in the extra-libraries field as normal. No
Setup.hs code or ./configure scripts are required (though it should work
with packages that do use ./configure scripts).

 A start would be to have hackage warn, I suppose.

I'm not quite sure what we can warn about here except the general use of
configure scripts (which is not a good idea at least at the moment). We
need to work out what everone is using them for first:
http://hackage.haskell.org/trac/hackage/ticket/482

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe