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 | [EMAIL PROTECTED] than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Thu, 16 May 2002, Malcolm Wallace wrote: > "Simon Marlow" <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users