finding the dependecies of cabal packages
kr.angelov at gmail.com
Mon Aug 1 07:23:20 EDT 2005
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.
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
> > 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.
> >> 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
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://www.haskell.org/mailman/listinfo/libraries
More information about the Libraries