> 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.
We'll schedule the combat for post-dinner at ParCFD - and hopefully that'll
diffuse some of the urgency. Let me be clear - this branch can be
maintained for a while, and I would fully expect to make another release on
the 0.7.x series with the current build system before merging this back and
going to 0.8.x...
>>> 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.
I'll continue to work this. I know how to have a single 'make' build
*everything* at once - opt, dbg,devel,etc... but that might be too much in
the other direction.
What would you think about ./configue --with-methods="opt, dbg, ..." and
builds them all in place?
>> 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.
Interestingly, automake caught an update to my installed mpi and trilinos
yesterday, which could easily be the source of these types of errors. And
as a plus we don't have to maintain our own (err, Wolfgang's) dependency
parser.
I'll also point out this has allowed me to build libMesh using pure Xcode
tools (autotools, compilers & mpi) as a shared library without having to
guess -flatten_namespace or whatever. How long do we need that flag? It is
even right? We have no idea really - it got added to our current build
system because it was the first thing we found that worked. How long will
it stay? No clue, but probably until it doesn't work in the future...
Let me emphasize that has never worked before.
So it is in that sense that I value a 'standard' build system - there is
just a lot to it that we should not have to concern ourselves with in the
future.
As for this:
> I think we need to get you access to MOOSE so you can see what we're dealing
> with here.
If that is easiest then fine. At this point I am trying to get other people
to test just libMesh with automake - like I said we have 10 years worth of
tweaks and I've thrown out what I think is unnecessary, so now I'm trying to
make sure it still works where it should. Before this goes back to trunk
we'll make sure that it works in MOOSE, or can easily.
>> 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)
Let me be clear on this too - as it stands right now you can install into
the same location with multiple methods. So your LIBMESH_DIR can point to
the install tree and it looks like this:
elfboy(107)$ ls -R /tmp/foo/{bin,lib}
/tmp/foo/bin:
i386-apple-darwin10.8.0_dbg i386-apple-darwin10.8.0_opt
/tmp/foo/bin/i386-apple-darwin10.8.0_dbg:
amr compare meshbcid meshid meshnorm meshtool projection
/tmp/foo/bin/i386-apple-darwin10.8.0_opt:
amr compare meshbcid meshid meshnorm meshtool projection
/tmp/foo/lib:
i386-apple-darwin10.8.0_dbg i386-apple-darwin10.8.0_opt
/tmp/foo/lib/i386-apple-darwin10.8.0_dbg:
libmesh.0.0.0.dylib libmesh.0.dylib libmesh.dylib libmesh.la
pkgconfig
/tmp/foo/lib/i386-apple-darwin10.8.0_dbg/pkgconfig:
Make.common Makefile libmesh.pc
/tmp/foo/lib/i386-apple-darwin10.8.0_opt:
libmesh.0.0.0.dylib libmesh.0.dylib libmesh.dylib libmesh.la
pkgconfig
/tmp/foo/lib/i386-apple-darwin10.8.0_opt/pkgconfig:
Make.common Makefile libmesh.pc
What you presently cannot do is run configure once and build multiple
methods. each method requires a separate invocation of configure, and I do
it in a different directory. but that part is not required. Like I said
earlier it would be easy to have a single "./configure ; make"
simultaneously build *all* the possible methods (if you like), but that
seems heavy handed to me. Honestly, how many people know about oprofile or
profile mode and want to devote the cycles to compiling that method?
>> 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.
c'mon - this *has* to work. what are the chances this serendipitously works
as is but wouldn't with a standard build system? As much as I'd like to
threaten you'll be forced to use vi that is simply nonsense.
>> 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.
Roy's right - there is no requirement to do a make install. in fact just
'make' will put meshtool and friends right in your build directory, and you
can run them from there if you like.
-Ben
------------------------------------------------------------------------------
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
