On Nov 21, 2012, at 7:21 PM, Derek Gaston <fried...@gmail.com> wrote:
> Let me explain a little more: I love libMesh. I think it's an awesome > triumph of scientific framework software. I am constantly in awe at all the > thought put into the way the system works. All of that thought went into > creating a library that presents an incredibly useful interface to it's users > and enables scientists and engineers to create complex parallel applications. > Because of this, I think the build system should be just as well thought > out... and just as easy to interact with. In the same way that you don't > have to be a parallel programming specialist or a computer scientist to use > libMesh... I don't think you should need to be a specialist to _build_ > libMesh. I don't want this great piece of software to be overlooked simply > because it is difficult to interact with the build system. Thanks for the vote of confidence, and I apologize for getting short with you over this… Let me explain my thinking here. It used to be that to use libMesh for anything useful you had to go through the hoops of building PETSc and/or Trilinos, so there was some expectation of competence there. But ever since you can 'apt-get install trilinos' and 'sudo port install petsc slepc' libMesh is the long pole - and even with the old build system. My goal would be to have libMesh integrated into the popular package managers, and that many users would be able to install the code that way. And the old build system was not getting us there. One major motivation for the new build system is to enable packaging in a standard way. That said, I concede that if group consensus in 6 months time is that this sucks and was the wrong move we can revert the build system. > As for our users. They do use a vetted version of _SVN_ libMesh. They are > not pulling from your repo, so they are insulated (for the moment) from these > changes. However, they _will_ use a version from SVN very soon (as soon as > either we make a change in libMesh that requires updating... or you guys add > some cool features that warrants an update). They will never use a release > version of libMesh. I can say, as Roy did, trunk has never been the go-to place for rock solid code. Releases are useful at least for fixing ideas, focusing everyone, and forcing a 'pencils down' code/feature cleanup. If you don't want to use them, that's fine - but you do benefit from them. Do you point your users to gcc/trunk, or petsc-dev? As libMesh matures, why would it be different? Oh yeah, Happy Thanksgiving to all!! -Ben ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
