On Nov 28, 2012, at 3:32 PM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> Adding such features via automake didn't become an order of magnitude > harder, did it? It looked as if ever since you added > contrib/Make.common things have been pretty clean in branch too. Agreed it is trivial on trunk, less so on branch - contrib/Make.common and examples/Make.common would each need a new set of rules, but look at ./Makefile.am If we can all agree a oprofile-verison of meshbcid or output_libmesh_version is pretty worthless, METHODS="opt gprof" is not quite as objectionable. > Making users set their own CXXFLAGS and CFLAGS, but not their own > CPPFLAGS, seems a bit arbitrary. I don't see it that way. I'd like to reserve METHODS for changing the fundamental nature of the library, not tweaking some compiler flags. Users are still free to modify CPPFLAGS too, but the point is opt is no asserts, devel is with asserts, and dbg is asserts plus sometimes some pedantic #ifdef DEBUG stuff. As an aside, I've got some application code which really hates -O3 with intel, but that doesn't warrant a METHOD=less_opt Of course, there's no technical reason we can't do it. Paul, as for this: >> Yeah, but with a --prefix you can put a pure opt somewhere and a gprof, >> oprofile, vtune, and whatever else comes along somewhere else. To me anyway >> this is much preferable to maintaining multiple method rules and targets. >> > This is my preference and how we would've done it anyway if there was a prof > METHOD (that is, there would've been a separate install for prof method from > opt, etc.). My 2 cents. I'm not sure I know what you mean here - are you saying you'd be OK with opt,dbg,devel and installing to different paths for profiling, or something else? -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
