Even just thinking about this topic makes me a bit ill. We have a fairly intricate build system built on top of libMesh's current build system that is in use by nearly 100 developers spread across all the national labs and several universities. We have put a _ton_ of work into this system, but it heavily relies on the Makefiles libMesh generates. It is a "cascading" build system where dependent libraries are automatically rebuilt as needed (it's necessary in our system where we have multiple "layers" with each layer being a separate library).
I don't want to be "that guy" but once again I have to say: it works pretty damn well the way it is. We never have any trouble compiling on even the most esoteric supercomputers. I can see two benefits of changing it: 1. Builds for multiple systems in the same tree. - Firstly, we could do this now, very easily, by just providing a different prefix / suffix for the different machines (just like we do with dbg, opt, devel) - Secondly, this just doesn't happen very often. We have a similar situation here at INL with multiple supercomputers and shared home directories, the way that we deal with this issue is by tying multiple libMesh checkouts together through a centralized Git repo in our home directory. In this way we can push and pull between different libMesh's for different machines. But… how often do we do that? Almost never. Generally we're working with _one_ machine at the moment. It's very rare to actually need to build modified versions of libMesh (which is where this would be useful… if it's just vanilla libMesh then I don't see the problem with having different directories for each machine) on multiple machines. I'm not saying it doesn't happen, but out of the millions of libMesh compiles a year by all of it's users, that has got to be close to 0.01% of the time. BTW: We just use a directory structure to manage this stuff like so ~/projectes/machine1/libMesh, ~/projectes/machine2/libMesh, etc… And for actual installed versions of libMesh on the machines those are handled through the "module" systems on those machines. 2. "make dist". This is becoming more important for us. We are going to have to start doing binary distributions pretty soon. If changing build systems would allow us to easily do that… then I might be for it. How hard would this be to do with our current build system? Derek On Feb 20, 2012, at 2:41 PM, Kirk, Benjamin (JSC-EG311) wrote: >> On Sat, 3 Jul 2010, John Peterson wrote: >> >>> On Sat, Jul 3, 2010 at 10:00 AM, Paul T. Bauman <ptbau...@gmail.com> wrote: >>> If there are no plans to change to autotools (or better, modern >>> build system *cough* SCons *cough*) then consider this a feature >>> request for "make install" behavior for the reasons listed in my >>> previous email. >>> >>> This would be my vote (add make install to existing build system) as well. >> >> I kind of liked that "we move to automake, but someone other than me >> does all the work" option. >> >> But just adding a "make install" target would be easier. >> >>> I think this is the biggest 'pro' you listed that we are currently >>> lacking... >> >> For me the only unlisted pro of automake is that IDEs understand it... >> but that's just based on my failed attempt to import libMesh into >> eclipse (or was it some KDE thing?) years ago; it may be outdated >> info. > > Consider this thread revived. In addition to not writing a make install in > the previous 18 months, there is another missing feature which I've recently > had an increased need for: proper VPATH builds. After a few years of > learning autotools for FIN-S I have a proper appreciation for it... > > Many ages ago we successfully introduced the METHOD concept as a way for > managing multiple build versions, but there is a serious Achilles heel - > Make.common must always be the same. So it is easy to build opt, dbg, devel > on the same platform, but forget managing a build for multiple systems out > of the same $LIBMESH_DIR. > > For me at least this would be a very nice feature - I currently maintain > three libmesh installations on different machines that can all see the same > filesystem because they all have different Make.common's. > > Derek made an argument agains autotools at one point because our current > system 'just works' - but I think that is more because it is properly > maintained. It is easy to write a poorly constructed autotools > installation, but a well constructed one will work as well as what we have. > > Plus, moving to a proper libtool installation will help in the future with > shared libraries on multiple platforms (yeah, looking at you OSX). > > Anyone have a serious change of heart in the past 18 months and would leave > the project if we did this? If not I might start a branch and see how bad > it gets... > > -Ben > > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! 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-d2d _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
