First: Thanks for the good reply. Good to see what's in your head on this subject. ;-)
On Mar 5, 2012, at 3:07 PM, Kirk, Benjamin (JSC-EG311) wrote: > Really - a no go? I guess then 'svn add' is simply asking too much of a > developer too? I'm just a believer in the "only store things in one place" paradigm (in databases you would call it normalization). Overall, having to store the same information in more than one place allows errors to creep in. You are right that it's not too burdensome… but when our current system picks this stuff up automatically it's hard to get excited about needing to remember to edit that file! >> This is really badŠ I can't even see having to explain this to our users. >> They just barely get the current METHOD=dbg stuffŠ but now there are >> different >> directories? Not only that but do you have to do a make install? How does >> LIBMESH_DIR work now?? Does it point to the build directory, to the install >> directory or to the source directory? Do you have to change it all the time >> to switch between METHOD's? > > The intent would be to have it point to the installl tree. Roy has > suggested a Make.common in there that dispatches from the proper > subdirectory based on the METHOD specified in the environment. I'll work to > implement that behavior. Yikes about having to install it. Where to install it? Right now everything is self-contained… I think we need to get you access to MOOSE so you can see what we're dealing with here. As things are they work perfectly… if you had to create a build directory _and_ and install directory…. it would get messy quickly. The way it is now there is just one directory (and it's even inside your repository checkout)… and everything is self contained and works just by doing "./configure; make"…. If we go down this path our users are going to need to have 7 directories for libMesh: the checkout, dbg:devel:opt builds, dbg:devel:opt installs…. and they're going to have to maintain those every time we make them update libMesh (with all the normal gnashing around because there will undoubtedly be old objects hanging out in the build directories…. so sometimes just rebuilding in those will work and sometimes not (and you'll have to destroy the directories)). Whereas right now all you have to do is a "make distclean" then rebuild with "./configure; make; METHOD=dbg make; METHOD=devel make" and then everything is sane. Compared to the new process: cd libmesh cd opt_build make * Damn it failed (some old .o's hanging around munged it up) cd .. rm -rf opt_build $LIBMESH_INSTALL_DIR/opt mkdir opt_build mkdir $LIBMESH_INSTALL_DIR/opt ../configure --method=opt --prefix=$LIBMESH_INSTALL_DIR/opt make make install cd .. * Pre-emptively know that the build will probably fail for dbg and devel: rm -rf dbg_build devel_build mkdir dbg_build ../configure --method=dbg --prefix=$LIBMESH_INSTALL_DIR/dbg make make install cd .. mkdir devel_build ../configure --method=devel --prefix=$LIBMESH_INSTALL_DIR/devel make make install cd .. I mean… seriously? Roy: Are you on board with this?? Don't you have the same issues with PECOS? Are all of your users prepared to do the above every time you tell them they have to update libMesh because you made changes to PECOS that are incompatible with any version of libMesh that isn't up to date? And now we're just talking about command-line stuff. What about all the cool Emacs stuff we have that builds libMesh in place just by pressing F8 (or Shift-F8 for debug). Are we going to change those macros to now create build directories, do configure, make and make install? Sure that's a small issue - but >> Maybe there is something I haven't explained yet: Our users have to rebuild >> libMesh quite often. We make backwards incompatible changes to libMesh and >> MOOSEŠ and it forces our users to need to rebuild libMesh. > > If they have to rebuild MOOSE why doesn't it handle building libMesh for > them in this case? Basically treat libMesh as a contributed package? Chicken and egg problem. We piggy back off your build system currently. So you have to build libMesh to build MOOSE. Maybe if you guys go down this path we'll switch that up! I suppose that we could steal your current build system then just inject the libMesh source into the MOOSE tree and call it a day…. hmmmm….. >> This isn't the >> type of thing where they do it once and then they can "make install" that >> version and use it for a long time. Adding complication to the libMesh >> rebuild process is bad. Bad enough that with this talk of using Automake >> we've started talking about meta-tools to build libMesh so we can insulate >> them from itŠ which is dumb because the current build system is good and >> simple enough that we don't need to do that... > > Our current build system works but has 10 years of bandaids on top of it. > It requires manual implementation of how to build shared libraries on all > supported platforms. I'm not convinced we do that 100% right on OSX and I'm > even less certain it won't change in a way the future that causes us a > headache. Definitely a possibility. > Also, we don't support a proper install target, and our current build system > is horribly complicated to integrate with RPM or .deb build systems. Would be cool. But none of us have tried with the current build system either. > That is the entire point of libtool. And like it or not, the autotools > chain is the de facto standard for development on *nix. If the preferred > method for building shared libraries changes with an OS release you can bet > the bundled libtool will know about it. > > Another benefit of a proper autotools implementation is 'make dist' - it > will package up a tarball that is itself *independent* of the autotools. > Even independent of GNU make - which is something we definitively can't do > at the moment. So if you have users which require building libMesh on an > archaic system why not just have them check out a self-sufficient tarball > from svn rather than the source tree? Could be useful. >> I'm sorry to sound so negative. I realize you've put a lot of time into >> thisŠ >> but as far as I can tell you've made one small situation somewhat easier >> (multiple out of directory builds on different machines sharing the same >> directory) and everything else has become more complicatedŠ > > I understand, I felt pretty much the same way when I asked Karl to wrap > autotools around FIN-S. I've come full circle on that though after having > used it from the developer and user perspective. Glad you have experience here… it's hard for me to see light at the end of this tunnel…. >> It feels like optimizing for developers and making users lives more >> complicatedŠ. which is really the opposite of what we should be doing. > > Well that is why at this stage I've posted this to the developers list - to > solicit some help in testing it. The end goal is to have a product which is > easier from the user perspective. Like API version checking and lots of > other nifty features. I administer a ton of different machines and install > a lot of software. While PETSc and Trilinos are by far there own beasts, > libMesh is itself an enigma. > > The whole > > $./configure > $ make && make check && make install > > thing is just plain standard - and we fall short. Do remember though: just because it's standard doesn't mean it's better. Not too mention that a ton of software is moving away from this model (either going with CMake like Trilinos or having a homegrown system or using one of the other random build capabilities out there). In particular: not having to do "make install" is a HUGE bonus. Yes… it might be a bit awkward if you really are going to try to install libMesh as a system-wide library (which we do every day on multiple different machines and architectures like yourself). But I contend that most libMesh users _don't_ use libMesh this way. libMesh is much closer to your application than something like mpich… it shouldn't necessarily be treated the same way as a system library… Derek ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
