Cabal compiling with profiling

Simon Marlow simonmar at
Wed Apr 20 05:00:07 EDT 2005

We could extend the .cabal syntax along the lines of:

Package: foo
Version: 1.0

extensions: CPP
extra-libraries: X11

ghc-options: -O2

ghc-options: -O0 -DDEBUG

and extend PackageDescription to include multiple BuildInfos, each with
an attached configuration tag.  How does that sound?  The .cabal syntax
remains backwards compatible.


On 20 April 2005 09:07, Krasimir Angelov wrote:

> What I have in mind is to have multiple .buildinfo files. One for each
> configuration. For example <pkg>.buildinfo.debug &
> <pkg>.buildinfo.release. Each hook can check for a specific
> --config=<..> command line option and will load the appropriate
> .buildinfo file. The disadvantage here is that in this way I need to
> maintain multiple files in addition to the central .cabal file.
> Another trouble is that with hooks API I cann't change the destination
> directory where the .hi and .o files are created. They all will go to
> dist/build while I need to keep them separated.
> It would be simpler if the Cabal library was aware of this
> configurations. In this case the configuration descriptions can be
> moved to .cabal file. We can have few predefined configurations like
> "Debug", "Release", "Profiling", ... which are always with predefined
> options. For Debug we can add -DDEBUG option to GHC, for Release -O
> option and maybe -split-obj and for Profiling -prof option. Of course
> we have to leave the user to change the default options and he have to
> be able to define its own configurations.
> Cheers,
>   Krasimir
> On 4/19/05, Isaac Jones <ijones at> wrote:
>> Krasimir Angelov <kr.angelov at> writes:
>>> We need something more general in VSHaskell. Usually each project in
>>> the Visual Studio environment has two configurations "Debug" and
>>> "Release" but the user can define his own configurations. The only
>>> difference between each configuration is in the command line
>>> switches passed to the compiler.
>> Or to the configure step?
>>> For Haskell projects this mean that each configuration will have
>>> different HookedBuildInfo associated. The profiling can be
>>> implemented in this more general framework if we add "Profiling"
>>> configuration. I still don't have clear design for configurations in
>>> Cabal. My first thought was that I can do this on top of hooks API
>>> but I am not sure whether it will be flexible enough.
>> Can you flesh this out a bit?  What do you mean by "configurations in
>> cabal"?  What are the issues that you're facing with the hooks?  We
>> need good feedback on the hooks.
>> peace,
>>  isaac
> _______________________________________________
> Libraries mailing list
> Libraries at

More information about the Libraries mailing list