On Mon, 5 Mar 2012, Derek Gaston wrote:
First: Thanks for the good reply. Good to see what's in your head on this
subject. ;-)
Whoa, whoa, let's cut down on the politeness level, everyone. I've
already decided that further disagreements here ought to be settled
via physical combat, and if you're only poking halfheartedly with the
spears then it'll be way less entertaining.
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!
Automake also stores things in only one place - the catch is that the
automake file is that place, rather than the directory structure.
Ironically the main value of doing that is to make it *easier* for
other projects to switch to automake, with no need to reorganize your
whole directory structure.
We'd clearly prefer to use the directory structure, but I don't know
of a way to do that with automake.
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…
The idea is to install it to whereever you'd previously have just left
the whole source tree. Makes things more self-contained, for a
narrower definition of self: your source code can be in read-only
directories, your object files can live with the source code or in
separate build trees, and your installation can include only the
development headers and libraries that are actually required by users.
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"….
This should still be doable. I'm usually lazy enough that even with
out-of-source builds I have the build directories be subdirs of the
main source directory, and install directories can be the same way if
you want.
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)).
Sadly, "just rebuilding will sometimes work and sometimes not" is the
current state of libMesh too. Vikram and I even manage to stumble
across a "make distclean didn't fix what rm -rf fixed" bug every
couple years, it seems.
Automake can (when it's done right, which I doubt will be right away)
even fix some of those cases - the generated Makefile can detect when
an svn update has futzed with its dependencies, and re-run whatever
part of the bootstrapping is necessary to replace anything out of
sync.
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
Okay, you've got to at least realize that *this* line is being unfair. ;-)
[script omitted]
I mean… seriously?
The nice thing about computers is, any time you anticipate yourself
having to run the same commands over and over again, you're halfway
done fixing the problem. I'd have preceded something similar to that
script with "cat >> libmeshmake" and ended it with something like
"svn add libmeshmake; svn commit"
Roy: Are you on board with this??
Yes, but only after Ben's fixed the serious problems you've identified
with it. (my definition of serious may be somewhat arbitrary: "you
can't yet use the same LIBMESH_DIR with multiple METHOD options"
counts as serious; whereas "you have to hand-add every new .C file to
a list" is just really aesthetically annoying)
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?
The PECOS users typically don't update libMesh. We build modules for
that (and PETSc, and to get a newer gcc and glpk, and for the kitchen
sink...) and it'll actually be easier to keep those modules up to date
with a "make install" target.
For non-PECOS regular users (regular defined as: doesn't need to edit
library code) I've helped with libMesh, eventually I'd like dpkg
control files and RPM spec files to be in our svn repo too, but a
"make install" is at least a good step.
And for power users I've helped with libMesh: although autotools isn't
great, it's at least a popularly familiar sort of good-enough.
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
It's not a trivial issue. It's a fixable issue, but not conveniently
- we'd basically do what some projects do, and have *all* the main
build system in a src/ subdirectory. Then we'd have a dead-simple
Makefile in the main directory which did all the build dir stuff for
you.
In particular: not having to do "make install" is a HUGE bonus.
Autotools doesn't actually *require* a "make install" either, does it?
I know it doesn't with executables; haven't tried skipping that step
with libraries. With executables, debugging with uninstalled libtool
files was confusing at first, but if you're already doing
"LIBMESH_RUN='gdb --args'", then
"LIBMESH_RUN='libtool --mode=execute gdb --args'"
isn't too much worse.
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…
If anything, though, the less of a "developer" and the more of a
"user" you are, the more you just want libMesh to act the same way all
your other libraries act. Even at the developer end of things, I'm
pretty much the ultimate bad example of "libMesh APIs don't do exactly
what I want, so instead of reworking my app I'll rework the library",
and still, based on recent work with other autotool-ized stuff I'm not
too wary about doing the same to libMesh.
---
Roy
------------------------------------------------------------------------------
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
