RE: Cabal compiling with profiling

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 wrote:

...

Krasimir Angelov 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries