Re: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools

Axel Simon

25 Nov 2010 25 Nov '10

5:16 a.m.

Dear Libraries, this message is on shortcomings of cabal with respect to automatically installing the gtk package which (a) depends on a package that contains only build tools (i.e. only binaries) and (b) has a big custom Haskell file Gtk2HsSetup.hs that Setup.hs has to import (and which is required in any package in the Gtk2Hs suite). This file is copied into every package of the Gtk2Hs suite which is a pain to maintain. On 25.11.2010, at 10:50, Lazycat Manatee wrote:

...

---------- Forwarded message ---------- From: Jens Petersen Date: 2010/11/25 Subject: Re: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools To: Andy Stewart

...
Jens Petersen writes:

...
I suggest moving Gtk2HsSetup.hs into a library, it could be part of gtk2hs-buildtools perhaps. How about it? It can't work.

Because we need Gtk2HsSetup.hs generate Signals.chs and Types.chs *before* any cabal depend check.

Hmm I haven't tested but don't really understand. You mean it will break builds with cabal-install? Doesn't gtk2hs-buildtools already do that? :)

Yes, but these are two separate show-stoppers: a) the gtk2hs-buildtools contains only binaries. It does not register as a package with ghc. Thus, if we make the gtk package depend on gtk2hs-buildtools, cabal would complain that (even after installing gtk2hs-buildtools) the gtk2hs-buildtools library is not there b) putting Gtk2HsSetup.hs in either gtk2hs-buildtools or any other library means that ./Setup.hs has to run to realize that this library is missing and that it needs to be downloaded. However, ./Setup.hs cannot be run because it imports Gtk2HsSetup.hs which is not yet available. I don't know if (b) can be solved by e.g. conditionally importing Gtk2HsSetup.hs if it is there and only installing libraries and re- invoking Setup.hs one this is done. This is a common trick in Makefiles, e.g. one could call make recursively to first build dependencies. Any suggestions welcome. Regards, Axel

Show replies by date

Claus Reinke

25 Nov 25 Nov

10:56 a.m.

New subject: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools

...

Yes, but these are two separate show-stoppers:

a) the gtk2hs-buildtools contains only binaries. It does not register as a package with ghc. Thus, if we make the gtk package depend on gtk2hs-buildtools, cabal would complain that (even after installing gtk2hs-buildtools) the gtk2hs-buildtools library is not there

Could it become a convention that tool packages install a library with tool paths (and other relevant configuration data)? Similar to ghc-paths. That way, the tool would be represented in the package database, and the paths would make use and configuration in dependent packages simpler.

...

b) putting Gtk2HsSetup.hs in either gtk2hs-buildtools or any other library means that ./Setup.hs has to run to realize that this library is missing and that it needs to be downloaded. However, ./Setup.hs cannot be run because it imports Gtk2HsSetup.hs which is not yet available.

There is MIN_VERSION_<package>(), so you might be able to check whether it is defined/has the right version, if it comes with the tools package. http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.ht... But, if the setup library is part of the tools package, and the latter becomes a dependency, wouldn't cabal install take care of that bit? Claus

...

I don't know if (b) can be solved by e.g. conditionally importing Gtk2HsSetup.hs if it is there and only installing libraries and re- invoking Setup.hs one this is done. This is a common trick in Makefiles, e.g. one could call make recursively to first build dependencies. Any suggestions welcome.

Regards, Axel

Antoine Latter

11:59 a.m.

New subject: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools

On Thu, Nov 25, 2010 at 9:56 AM, Claus Reinke wrote:

...

...
b) putting Gtk2HsSetup.hs in either gtk2hs-buildtools or any other library means that ./Setup.hs has to run to realize that this library is missing and that it needs to be downloaded. However, ./Setup.hs cannot be run because it imports Gtk2HsSetup.hs which is not yet available.

There is MIN_VERSION_<package>(), so you might be able to check whether it is defined/has the right version, if it comes with the tools package.

Does that work in Setup.hs? I thought that these CPP macros were generated by the 'confgure' step, which may not have been run yet.

...

http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.ht...

But, if the setup library is part of the tools package, and the latter becomes a dependency, wouldn't cabal install take care of that bit?

Claus

...
I don't know if (b) can be solved by e.g. conditionally importing Gtk2HsSetup.hs if it is there and only installing libraries and re- invoking Setup.hs one this is done. This is a common trick in Makefiles, e.g. one could call make recursively to first build dependencies. Any suggestions welcome.

Regards, Axel

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Claus Reinke

12:43 p.m.

New subject: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools

...

...
...
b) putting Gtk2HsSetup.hs in either gtk2hs-buildtools or any other library means that ./Setup.hs has to run to realize that this library is missing and that it needs to be downloaded. However, ./Setup.hs cannot be run because it imports Gtk2HsSetup.hs which is not yet available.

There is MIN_VERSION_<package>(), so you might be able to check whether it is defined/has the right version, if it comes with the tools package.

Does that work in Setup.hs? I thought that these CPP macros were generated by the 'confgure' step, which may not have been run yet.

argh. You're right - the macros are not available in Setup.hs. I keep forgetting that because it would be useful to have them there http://hackage.haskell.org/trac/hackage/ticket/326 So, if putting the file into the tools package doesn't suffice, we'd be back to passing in CPP macros from .cabal files (or using a front Setup.hs to check the configuration info before calling out to a version-specific SetupX.hs). Claus

Axel Simon

26 Nov 26 Nov

2:47 a.m.

New subject: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools

Hi Claus, On Nov 25, 2010, at 18:43, Claus Reinke wrote:

...

...
Yes, but these are two separate show-stoppers:

a) the gtk2hs-buildtools contains only binaries. It does not register as a package with ghc. Thus, if we make the gtk package depend on gtk2hs-buildtools, cabal would complain that (even after installing gtk2hs-buildtools) the gtk2hs-buildtools library is not there

Could it become a convention that tool packages install a library with tool paths (and other relevant configuration data)? Similar to ghc- paths.

That way, the tool would be represented in the package database, and the paths would make use and configuration in dependent packages simpler.

I think this is a hack. For instance, it means that any application that uses any Gtk2Hs package would depend on gtk2hs-buildtools which is not really true and unnecessary. Does one really want extra executables (aka the build tools) lying around for any Gtk2Hs application? I think not. This is the case at the moment, but I think cabal should have the ability to install build tools for a package and possibly even remove them once the package has been built.

...

...
...
...
b) putting Gtk2HsSetup.hs in either gtk2hs-buildtools or any other library means that ./Setup.hs has to run to realize that this library is missing and that it needs to be downloaded. However, ./Setup.hs cannot be run because it imports Gtk2HsSetup.hs which is not yet available.

There is MIN_VERSION_<package>(), so you might be able to check whether it is defined/has the right version, if it comes with the tools package.

Does that work in Setup.hs? I thought that these CPP macros were generated by the 'confgure' step, which may not have been run yet.

argh. You're right - the macros are not available in Setup.hs. I keep forgetting that because it would be useful to have them there

http://hackage.haskell.org/trac/hackage/ticket/326

So, if putting the file into the tools package doesn't suffice, we'd be back to passing in CPP macros from .cabal files (or using a front Setup.hs to check the configuration info before calling out to a version-specific SetupX.hs).

I tend to think that a recursive call to a different Setup.hs would be the best solution. The question is what features must be available in the outer Setup (checking for installed packages and being able to install those that are missing, for example) and which ones do we only need in the inner Setup (knowing the exact cabal version). Regards, Axel

Duncan Coutts

30 Nov 30 Nov

6:43 p.m.

New subject: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools

On Thu, 2010-11-25 at 11:16 +0100, Axel Simon wrote:

...

Dear Libraries,

this message is on shortcomings of cabal with respect to automatically installing the gtk package which (a) depends on a package that contains only build tools (i.e. only binaries) and (b) has a big custom Haskell file Gtk2HsSetup.hs that Setup.hs has to import (and which is required in any package in the Gtk2Hs suite). This file is copied into every package of the Gtk2Hs suite which is a pain to maintain.

I don't have any easy answers. The "right solution" for (a) is for cabal-install to track build tools (and C libs and all other dependencies, not just Haskell libs). For dependencies of Setup.hs, this is also hard. The original Cabal spec envisioned Setup.hs scripts being self-contained having no deps other than the base libs and Cabal itself, since this was intended as the primary user interface, so it must compile without a lot of fuss. In principle for some future Cabal spec revision we could add some way to declare that the build system itself requires certain dependencies. I also hope that the size of the Gtk2Hs Setup.hs can eventually be reduced by supporting c2hs in Cabal properly (i.e. including .chs dependencies). Duncan

5286

Age (days ago)

5291

Last active (days ago)

List overview

Download

5 comments

4 participants

participants (4)

Antoine Latter
Axel Simon
Claus Reinke
Duncan Coutts