Cabal compiling with profiling

[Simon Marlow]

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

Package: foo
Version: 1.0
etc.

extensions: CPP
extra-libraries: X11

[Release]
ghc-options: -O2

[Debug]
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.

Cheers,
	Simon


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 syntaxpolice.org> wrote:
>> Krasimir Angelov <kr.angelov at gmail.com> 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 haskell.org
> http://www.haskell.org/mailman/listinfo/libraries