Cabal compiling with profiling

[Krasimir Angelov]

Yes. It is esential to keep one main BuildInfo where all common
options are kept and one additional BuildInfo per configuration.

On 4/20/05, Simon Marlow <simonmar at microsoft.com> wrote:
> 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
> 
>