From: Jens P. <pet...@ha...> - 2010-10-02 05:58:52
|
I suggest moving Gtk2HsSetup.hs into a library, it could be part of gtk2hs-buildtools perhaps. How about it? Jens |
From: Andy S. <laz...@gm...> - 2010-10-02 08:21:12
|
Hi Jens, Jens Petersen <pet...@ha...> 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. -- Andy |
From: Jens P. <pet...@ha...> - 2010-11-25 12:18:36
|
[sigh forget to click reply-all earlier...] >>> Jens Petersen <pet...@ha...> 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 Right > 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. Perhaps. I guess I was just trying to say that having Gtk2HsSetup in gtk2hs-buildtools still seems better to me even if Setup is broken! :) Not claiming it is a good solution just better than having a copy-library IMHO... But I hear your reluctance to do my hack. :) Sure in the long turn Cabal should be improved for this case... Jens |
From: Axel S. <Axe...@in...> - 2010-11-25 13:26:43
|
On 25.11.2010, at 13:18, Jens Petersen 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. >> >> 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. > > Perhaps. I guess I was just trying to say that having > Gtk2HsSetup in gtk2hs-buildtools still seems better to me > even if Setup is broken! :) > > Not claiming it is a good solution just better than having > a copy-library IMHO... But I hear your reluctance to do my hack. :) > > Sure in the long turn Cabal should be improved for this case... How would this hack work? You suggest that Setup.hs fails to compile if the gtk2hs-buildtools package is not installed? That might work, but the error message will confuse users. Axel |
From: Andy S. <laz...@gm...> - 2010-11-25 14:05:31
|
Jens Petersen <pet...@ha...> writes: > [sigh forget to click reply-all earlier...] > >>>> Jens Petersen <pet...@ha...> 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 > > Right > >> 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. > > Perhaps. I guess I was just trying to say that having > Gtk2HsSetup in gtk2hs-buildtools still seems better to me > even if Setup is broken! :) > > Not claiming it is a good solution just better than having > a copy-library IMHO... But I hear your reluctance to do my hack. :) Yes, maintain Gtk2HsSetup.hs is painful, we need update all gtk2hs-base packages once we update something in Gtk2HsSetup.hs. > > Sure in the long turn Cabal should be improved for this case... It's Cabal' fault, sadly. -- Andy |
From: Jens P. <pet...@ha...> - 2010-11-25 14:47:35
|
On 25 November 2010 23:26, Axel Simon <Axe...@in...> wrote: > You suggest that Setup.hs fails to compile if the > gtk2hs-buildtools package is not installed? I hadn't really thought it through when I originally suggested it, but yeah pretty much... given that gtk2hs-buildtools is needed for nearly all the packages anyway it doesn't seem so big a deal to me. Anyway I understand if you prefer to keep copying Gtk2HsSetup for now. :) Of course it might faster to write a patch for Cabal. :) Jens ps (The only helper I can think of would be a configure script but that would break the platform neutrality again of course.) |
From: Duncan C. <dun...@go...> - 2011-04-20 19:31:02
|
On Fri, 2010-11-26 at 00:47 +1000, Jens Petersen wrote: > On 25 November 2010 23:26, Axel Simon <Axe...@in...> wrote: > > You suggest that Setup.hs fails to compile if the > > gtk2hs-buildtools package is not installed? > > I hadn't really thought it through when I originally suggested it, > but yeah pretty much... given that gtk2hs-buildtools is needed > for nearly all the packages anyway it doesn't seem so big a deal to me. > Anyway I understand if you prefer to keep copying Gtk2HsSetup for now. :) > > Of course it might faster to write a patch for Cabal. :) Yes. What is needs is an addition to the Cabal spec and an implementation in the Cabal lib and cabal-install tool. We need to be able to specify that the *build system* for the package depends on the given packages. Currently it is assumed that the Setup.hs will just magically compile, which means it is assumed that it depends only on the core libs that are always available (which includes the Cabal lib). Anyone implementing a totally custom build system runs into this problem. It's on the TODO list for Cabal 2.x but it would not hurt to do it sooner. Patches most welcome :-) Duncan |