headers
Ross Paterson | 1 Aug 2005 01:25
Picon
Favicon

Re: fptools/libraries package versioning

On Sun, Jul 31, 2005 at 01:50:20PM -0500, Brian Smith wrote:
>  Okay. But, then how can I document that these new functions are not in 
> Win32-1.0? I would like to say, for example "Introduced in version 1.1" in 
> the documentation. That is what made me think that the version number needs 
> to be bumped (only) during the first API change after a release.

These intermediate versions differ from 1.0, but they will also differ
from 1.1, and each other.  If you build a source distribution with setup
sdist --snapshot, they will be given versions 1.0.YYYYMMDD, which lie
between the two.  This works if you increment on release (and don't
change the depth of numbering).

>> Note that the graphics part of the Win32 package fails under GHC.
> 
>  Do you know why? I noticed that when I build Win32 using Cabal, 
> genericWndProc and DeleteObject do not get linked correctly. I think it is a 
> problem with "dynamic" imports. But, I don't know if it is related to the 
> problem you are talking about.

I have no personal experience with it.  SimonM reported:
> [The test programs] still don't do much.  If I compile with -threaded,
> then the HelloWorld program pops up a window, but the cursor is an hour
> glass and it doesn't do anything else.  The [HGL examples] either hang,
> or if I use -threaded they re-enter the scheduler.
Permalink | Reply | 0 comments |
headers
Krasimir Angelov | 1 Aug 2005 08:58
Picon
Gravatar

Re: MySQL / HSQL Won't Build

The problem is that hsc2hs doesn't recognize all flags from
'mysql_config --cflags'. The hsc2hs tool have to receive only -I and
-D options from cc-options field in the .cabal file. This is fixed in
the recent (CVS) Cabal version but it isn't available in the current
release. I discovered the trouble shortly after the last HSQL release.
You can change the package description manually to workarround the
trouble.

Cheers,
  Krasimir

On 7/31/05, Bjorn Bringert <bringert <at> cs.chalmers.se> wrote:
> Dominic Steinitz wrote:
> > I've just downloaded and tried to build HSQL for MySQL but I'm getting the
> > errors below. mysql.h does exist. Any help would be appreciated.
> >
> > Thanks, Dominic.
> >
> > [dom <at> tility MySQL]$ ls /usr/include/mysql/mysql.h
> > /usr/include/mysql/mysql.h
> >
> > [dom <at> tility MySQL]$ ghc Setup.lhs -o Setup -package Cabal-1.0.1
> >
> > [dom <at> tility MySQL]$ ./Setup configure
> > Warning: No license-file field.
> > Configuring hsql-mysql-1.6...
> > configure: Using install prefix: /usr/local
> > configure: Using compiler: /usr//bin/ghc
> > configure: Compiler flavor: GHC
> > configure: Compiler version: 6.4
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Aug 2005 11:05
Picon
Favicon

RE: on when to build ghci libs in cabal

On 30 July 2005 21:05, Isaac Jones wrote:

> Henning Günther and Duncan Coutts / the Gentoo team have sent me a
> patch to move creation of ghci libs to the build phase rather than the
> register phase.  It makes more sense there and should be somewhat
> better for debian and gentoo.
> 
> Though Duncan points out that maybe some ppl want to build the ghci
> libs during register because it could save room in a binary
> distribution (like debian and rpm).  Any opinions here?
> 
> Also, I noticed the "FIXME" that mentions the -x flag is only
> supported on some platforms; what effect will this have on platforms
> that don't support it?  Will they be broken during build?  What about
> platforms where we know the ghci libs don't work, like MacOS; will
> this patch cause building to break?
> 
> The patch adds a couple extra configure options,
> --enable-library-for-ghci / --disable-library-for-ghci.  I'm sorta
> thinking of just having one option "--disable-interpreter-libs" or
> something to make this seem more generic, though at the moment, it
> still only makes sense for a combo compiler / interpreter build (that
> is, --ghc).  I'll be happy to add this to the manual once we settle on
> a flag.  Do we ever really need to disable it anyway?

Definitely a good thing.  The ghc-pkg --auto-ghci-libs was only ever a hack, because it doesn't make any
attempt to find the right way to build GHCi libs on the current platform; Cabal can do a much better job.  I'm
happy we're shifting this burden onto Cabal.

I'm not sure you would ever want to disable it; it should be completely transparent.  Arguably GHCi should be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Aug 2005 11:24
Picon
Favicon

RE: finding the dependecies of cabal packages

On 29 July 2005 23:19, Isaac Jones wrote:

> Brian Smith <brianlsmith <at> gmail.com> writes:
>> I think what VHS.NET does--and what I am/was planning to do--is use
>> Cabal files as projects, but reimplement Distribution.Simple.Build
>> et. al. to work in an better in an "interactive" GUI environment
>> than the current system, which is batch-compile oriented. In
>> particular, VHS.NET and maybe my tool will use the GHC API
>> extensively. 
>> 
>> For example, using the GHC API I can do dependency analysis that will
>> allow me to say "build just this one source file because that other
>> source file changed." But, Cabal always restarts dependency analysis
>> over at the root modules, which make it too slow for interactive use.
> 
> (snip)
> 
> Why not work to speed up Cabal's execution time rather than
> reimplement so much from scratch, and in a compiler-dependent way?
> 
> There's nothing inherent about Cabal's interface that makes it do
> things in a batch, or slows compilation time.  It uses GHC's --make
> flag (though it always relinks the library, which is not always
> necessary).
> 
> If your tool is written in Haskell, and could be made compiler
> agnostic, perhaps we could add such features to cabal itself... maybe
> we could have a "./setup build --continuous" which emits status to a
> file or uses a socket interface or something in order to communicate
> w/ eclipse, VS, and your tool, since they often want the same kind of
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Marlow | 1 Aug 2005 11:32
Picon
Favicon

RE: finding the dependecies of cabal packages

On 29 July 2005 21:18, Duncan Coutts wrote:

> However an IDE wants even more. It wants to be able to rebuild
> individual files quickly (so dependency tracking is required and
> linear build scripts are out). It will want to provide a GUI
> interface for changing build system parameters (which means that the
> build system has to be declarative, not scripted). And no doubt there
> are other things too.
> 
> The point is that fulfilling these requirements might be possible for
> some imagined future version of the "simple" build system, however if
> the Cabal interface is extended to stipulate these same features then
> it would exclude most other build system implementations.

My feeling is that the requirements for incremental building should be
part of the simple build system.  

It's not quite true now, because we allow arbitrary hooks into the
simple build system.  So tools like Visual Haskell only work properly if
you don't use hooks.  This is one reason why being more explicit about
whether a package uses hooks or not would be useful.

Cheers,
	Simon
Permalink | Reply | 1 comment |
headers
Krasimir Angelov | 1 Aug 2005 12:23
Picon
Gravatar

Re: finding the dependecies of cabal packages

On 8/1/05, Simon Marlow <simonmar <at> microsoft.com> wrote:
> Using this abstraction, we could construct "ghci --cabal" very easily.
> Using it in Visual Haskell would be tricky, because I believe we have a
> different internal representation of PackageDescription.

I don't know what "ghci --cabal" mean, but I think that our internal
representation of PackageDescription could be useful in other
applications too. The difference between PackageDescription and our
representation is that the latter is more useful when you want to
interactivelly edit the package description. The advantage of
PackageDescription is that it is simpler and it is easier to
parse/pretty print values of this type.

Cheers,
  Krasimir
Permalink | Reply | 0 comments |
headers
Krasimir Angelov | 1 Aug 2005 12:31
Picon
Gravatar

Re: finding the dependecies of cabal packages

Visual Haskell works quite well with hooks. We are already using hooks
in order to build Visual Haskell itself. In Visual C++ projects you
can specify a sequence of shell commands which can be executed at
specified point in the build process. In Visual Haskell you can use
Cabal hooks to perform the same actions but the hooks approach is more
flexible.
The only limitation of Visual Haskell is that it can work only with
the simple build architecture. It can be extended with the makefile
based system but the drawback will be that we will lose the project
editing features, interactive type checking and all other advanced
features. The situation is the same with the Makefile based Visual C++
projects. Visual C++ provides only basic support for Makefiles.

Cheers,
  Krasimir

On 8/1/05, Simon Marlow <simonmar <at> microsoft.com> wrote:
> On 29 July 2005 21:18, Duncan Coutts wrote:
> 
> > However an IDE wants even more. It wants to be able to rebuild
> > individual files quickly (so dependency tracking is required and
> > linear build scripts are out). It will want to provide a GUI
> > interface for changing build system parameters (which means that the
> > build system has to be declarative, not scripted). And no doubt there
> > are other things too.
> >
> > The point is that fulfilling these requirements might be possible for
> > some imagined future version of the "simple" build system, however if
> > the Cabal interface is extended to stipulate these same features then
> > it would exclude most other build system implementations.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Aug 2005 13:09
Picon
Favicon

RE: finding the dependecies of cabal packages

On 01 August 2005 11:31, Krasimir Angelov wrote:

> Visual Haskell works quite well with hooks.

Hmm, I'm not sure it does.  The hooks are only run when building the
project, not when interactively editing the source code.  We can't
discover what hooks are being used, because they are embedded in the
Setup.lhs script.

If we knew what the hooks were, then we could run them from VS (security
issues aside).  It's not entirely clear when to run the
preBuild/postBuild hooks given that we're essentially building
continuously, but I'm sure doing something simple will work most of the
time.

> We are already using hooks
> in order to build Visual Haskell itself. In Visual C++ projects you
> can specify a sequence of shell commands which can be executed at
> specified point in the build process. In Visual Haskell you can use
> Cabal hooks to perform the same actions but the hooks approach is more
> flexible.
> The only limitation of Visual Haskell is that it can work only with
> the simple build architecture. It can be extended with the makefile
> based system but the drawback will be that we will lose the project
> editing features, interactive type checking and all other advanced
> features. The situation is the same with the Makefile based Visual C++
> projects. Visual C++ provides only basic support for Makefiles.
> 
> Cheers,
>   Krasimir
(Continue reading)

Permalink | Reply | 501 comments |
headers
Simon Marlow | 1 Aug 2005 13:21
Picon
Favicon

RE: finding the dependecies of cabal packages

[ oops, hit send by mistake ]

On 01 August 2005 11:31, Krasimir Angelov wrote:

> Visual Haskell works quite well with hooks.

Hmm, I'm not sure it does.  The hooks are only run when building the
project, not when interactively editing the source code.  We can't
discover what hooks are being used, because they are embedded in the
Setup.lhs script.

The preXXX hooks are a one-way mechanism for obtaining the
PackageDescription: there's no way to re-inject a modified
PackageDescription.  The postXXX hooks, on the other hand, are fine.  As
long as you stick to postXXX hooks, then VH works fine, because the
PackageDescrption is static and in a known place.

This isn't an argument against hooks, just an observation that (a) there
are uses of hooks that work fine with an IDE, (b) there are uses of
hooks that don't, and (c) the IDE can't tell whether a package is even
using hooks, let alone whether it is using safe hooks or not.  We should
at least do something about (c).  Sorry for not bringing this up when
hooks were being discussed...

Cheers,
	Simon

> We are already using hooks
> in order to build Visual Haskell itself. In Visual C++ projects you
> can specify a sequence of shell commands which can be executed at
(Continue reading)

Permalink | Reply | 0 comments |
headers
Krasimir Angelov | 1 Aug 2005 13:23
Picon
Gravatar

Re: finding the dependecies of cabal packages

Yes! You are right but the hooks are still useful as long as they
don't change the compilation process. A good example is the postConf
hook which I have in HSQL. It performs some checks and after that it
returns HookedBuildInfo. This doesn't prevent HSQL to be build from
Visual Studio. An another example is the postBuild hook which allows
to do some magic after the main build process.

Cheers,
  Krasimir

On 8/1/05, Simon Marlow <simonmar <at> microsoft.com> wrote:
> On 01 August 2005 11:31, Krasimir Angelov wrote:
> 
> > Visual Haskell works quite well with hooks.
> 
> Hmm, I'm not sure it does.  The hooks are only run when building the
> project, not when interactively editing the source code.  We can't
> discover what hooks are being used, because they are embedded in the
> Setup.lhs script.
> 
> If we knew what the hooks were, then we could run them from VS (security
> issues aside).  It's not entirely clear when to run the
> preBuild/postBuild hooks given that we're essentially building
> continuously, but I'm sure doing something simple will work most of the
> time.
> 
> 
> > We are already using hooks
> > in order to build Visual Haskell itself. In Visual C++ projects you
> > can specify a sequence of shell commands which can be executed at
(Continue reading)

Permalink | Reply | 501 comments |

Gmane