Cabal compiling with profiling
simonmar at microsoft.com
Wed Apr 20 05:00:07 EDT 2005
We could extend the .cabal syntax along the lines of:
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.
> 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.
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries