On Mon, Mar 5, 2012 at 5:42 PM, Derek Gaston <fried...@gmail.com> wrote:
>
> 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….
This is wrong. You have 4 directories - source tree, and dbg/devel/opt
installs. Why would you keep the build around? There's no need - everything
that you need is installed (and then some...). In fact, it adds clarity
because the directory is reflecting what version you've built against, as
opposed to forgetting to swap out $METHOD and you link against the wrong
one (happened several times around here with multiple users).
> 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?
>
Really, you can't encapsulate this once as a build script and be done and
give it to your users?
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?
>
Roy can speak for himself and his point-of-view on this, but I can speak
about what goes on in PECOS. The users don't do any of the above. They use
modules to load the environment, then either Roy or myself build things up
as needed. In fact, we have build scripts for everything so it's automated.
But, precisely the point you bring up about incompatible changes is
precisely why there *should* be an install method - I don't want to have to
worry about him tinkering in trunk when I'm trying to setup production
runs. I want the version we're going to run with installed and he can
continue to tinker in the source tree.
>
> > 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.
>
This is incredibly useful. It makes putting things on other supercomputing
systems *much* easier, for example.
> >> 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….
>
I kicked and screamed about having to do Autotools around here (as opposed
to SCons), but after having built at least 4 build systems using Autotools,
it is hard to argue with being able to plug in existing m4 files for
configure checks, very easy (although somewhat cumbersome) build system
construction with Automake, and *very* easy incorporation of unit and
regression testing, while getting things like make install and make dist
almost for free. And I don't mean little piss ant builds, I mean linking
against 10 different libraries and porting to my mac laptop, modern ubuntu,
archaic rhel systems, and two different supercomputing environments.
> >
> > 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).
>
Have you tried CMake? I'm not a fan. But even CMake works the same way -
configure; make; make install. In fact, you *can't* do in-source builds (at
least, not in the libraries I've used that use CMake) - you have to install.
Regarding libMesh, the ability for the user to run make check to check the
correctness of the installation (and I mean not just the examples, but
getting unit tests in there too) and being able to install into a
standalone directory is better than what was there, IMHO.
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…
I disagree with this. libMesh is designed to be a library. While you can
make your code be intimately dependent upon it, there's no reason to force
that. I have several libMesh dependent codes that leverage many other
libraries. I do use libMesh precisely as a standalone library. This is why
I've been dumping quite a few hours in with Ben getting this working.
Paul
------------------------------------------------------------------------------
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
