On Wed, 28 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote: > 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
Ah; the utility programs. That is a bit messy. No way to refactor it without giving each utility its own subdirectory, either, is there? No loops or pattern-matching variable operations in automake? > If we can all agree a oprofile-verison of meshbcid or > output_libmesh_version is pretty worthless, Agreed. Likewise for gprof or even devel versions; basically if everything's working right then we want opt for our utilities; if we feed them a bad input and something breaks then we want full-on dbg. > METHODS="opt gprof" is not quite as objectionable. I'd hope not. I know I'm probably the only one using oprofile, but I know I'm not the only one who's benefitted from some of the optimization opportunities it identified. There's a meta-question here: "should we remove oprof support if only Roy is directly using it" is just a special case of "should we remove features with N users which require maintenance of M lines" - surely the answer for N=1, M=15 is no!? If not, what's our M for N=2? For N=3? >> 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. So should we remove every flag in compiler.m4 which doesn't change the fundamental nature of the library: take out -O2 -felide-constructors -g -ansi -pedantic -Wall -Wno-long-long -library=stlport4 -qrtti=all -ftz (and so on) and just leave CPPFLAGS alone as the difference between debug/devel/opt? Would the reaction be "thanks for eliminating the maintenance of hundreds of lines of m4 code" or "why did my stuff stop working right"? > 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. --- Roy ------------------------------------------------------------------------------ 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
