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

[Hal Daume III]

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" <simonmar@microsoft.com> 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
>