On 3/5/12 1:08 PM, "Derek Gaston" <fried...@gmail.com> wrote:
> FirstlyŠ I'm still against this idea. I think it's adding complication to > something that currently works well for the majority of users and use cases. Understood. > On Mar 5, 2012, at 11:16 AM, Kirk, Benjamin (JSC-EG311) wrote: > > (1) files must manually be added to ./Makefile.am and ./include/Makefile.am > > For me, this would be a no go. Surely there is a a way to do this > automatically. This just doesn't make sense. Really - a no go? I guess then 'svn add' is simply asking too much of a developer too? Seriously though, while it can probably be automated it is very much along those lines. For someone contributing to libmesh who is adding files to the build system this is not a burdensome requirement. > (2) METHOD is now a configure-time variable. Multiple build methods are still > supported and are properly installed into different paths, but must be built > from different directories. For example, I handle it like this: > > $ ./bootstrap > $ mkdir $METHOD > $ cd $METHOD > $ ../configure Š > > 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. > 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? > 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. 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. 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? > 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. > 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. ------------------------------------------------------------------------------ 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
