Re: Giving profiled object files a different extension (was: RE: Profiling suggestion)

For what it's worth (I don't know whether defaulting -prof to mean '-prof -osuf p_o -hisuf p_hi' was going to be adopted or not), but I'm against it. I name my o file by $ARCH.o and my hi files by $ARCH.hi and profiled by $ARCH.p.o, etc...I basically do this by aliasing in my .cshrc ghc to ghc -osuf $ARCH.o -hisuf $ARCH.hi; this means I don't have to worry about "make clean"ing every time I build for different architectures (I usually have a sun4 build and a linux i686 build laying around). I then have another alias ghcp for profiling which uses -osuf $ARCH.p.o, etc. As long as this default is overridden by explicit options, I'm fine with it, but please don't hardwire it :). - Hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Thu, 16 May 2002, Malcolm Wallace wrote:

"Simon Marlow" writes:

...

...

Re the current and recurring conflicts between profiling and non-profiling code; how hard would it be to name GHC's output files differently when compiling with -prof?

The proposal, therefore, is to extend the meaning of '-prof' to mean '-prof -osuf p_o -hisuf p_hi' or similar.

It might be worth pointing out that nhc98 already does something like this, and we find that it is definitely a big win. We settled on .p.o for heap profiling and .z.o for time profiling (also .T.o for tracing, but that may disappear shortly with the advent of portable Hat).

...

To summarise the advantages/disadvantages: - win: you could store profiled and normal objects in the same directory.

Very handy, because it means you can switch between normal and profiled versions of a project without having to do a complete rebuild every time.

...

- win: you'd be less likely to mix up profiled and normal objects.

Mixing up object files was an absolute pain in the backside, and happened far too frequently, until we adopted separate suffixes.

...

- lose: Makefile writing gets harder. Extra suffix rules have to be added to deal with the new suffixes, and 'make depend' has to add dependency rules for the extra suffixes (ghc -M has some support for doing this). If you're using ghc --make this doesn't affect you.

Worth noting also that `hmake' currently understands that -p (for nhc98) means to look for the .p.o suffix etc. It would be very straightforward to extend the mechanism to do the same or similar for ghc.

Regards, Malcolm _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users