On Nov 26, 2012, at 4:43 PM, "Kirk, Benjamin (JSC-EG311)" 
<benjamin.kir...@nasa.gov> wrote:

> On Nov 26, 2012, at 4:33 PM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> 
>> f the hassle of multiple targets is just too annoying, maybe direct
>> support in configure isn't the way to go? 
> 
> I'll see what the general consensus is - it really isn't too bad, all of the 
> contrib/*/Makefile.am's are pretty boilerplate, save for fparser ;-)
> 
> I could easily do the same trick, set up each contributed package in a 
> generic way to build 
> 
> libcontrib-opt.la
> libcontrib-dbg-la
> libcontrb-devel.la
> 
> and then accumulate all of them at the top level.  This is similar to what I 
> am doing now with the examples (in libmesh.automake)

Done on that branch in r6454.

Still looking for more feedback, but I'm actually starting to like the multiple 
method approach, and I've restructured a lot of the Makefile.am's to make the 
implementation clean.

Derek, this should address the cd hassle for you.  Of course subdirectory 
builds still work, and I really like these to segregate builds by compiler or 
machine - while still sharing the same source tree - but it is no longer 
required to get multiple methods.

Also, --disable-examples is implemented and does what you'd expect - perhaps 
most importantly speeding up make install.

Finally, I got frustrated that reconfigure forced a major rebuild. This was 
because we were textually time-stamping the autoconf-generated headers with the 
time at which configure was invoked.  This information is not that useful, and 
triggered a lot of unnecessary rebuilds, so I got rid of it.  Of course, 
libmesh_here() etc… still has access to the *compiled* date, which is arguably 
more relevant anyway. Importantly, though, 

$ ./configure …
$ make …
$ ./configure ..
$ make # is now a no-op!

So, as usual, I created a "feature" branch and turned it into a "kitchen sink 
update" branch.  Sorry about that - its hard to be disciplined and only change 
one thing at a time…

To summarize - I think this is a good move, if consensus is it is in the 
direction of good I'll merge and then start updating the installation 
instructions on the web page.  So please check this out.

-Ben


------------------------------------------------------------------------------
Keep yourself connected to Go Parallel: 
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to