>> As an aside, I've got some application code which really hates -O3 >> with intel, but that doesn't warrant a METHOD=less_opt > > No, but it might warrant pinpointing that intel version and switching > opt to use -O2 there. I'm not suggesting that we want METHOD=opt and > METHOD=opt_for_broken_intel support any more than we want > METHOD=opt_intel versus METHOD=opt_gcc support - multiple METHODS are > for situations where you might want to support simultaneous > compilation of the same code with multiple settings. It's not > common but not unreasonable to want to debug, optimized-run, and > profile the same code.
Oh hell, I really don't care that much and am willing to add oprofile (or was it gprof, or what anyway??) I'm mostly interested in doing it just once - I'm hopeful the libmesh.automake branch multi-method approach is an agreeable one, and I'll do it there. -Ben ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
