On Nov 24, 2012, at 2:00 PM, Roy Stogner <royst...@ices.utexas.edu> wrote:

> 
> On Sat, 24 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
> 
>> $ ./configure METHODS="opt dbg devel"
>> 
>> and have it create a subdirectory for each, the only catch then is a
>> 
>> $ make
>> 
>> will *always* recurse into each.  In fact, I can add that alongside
>> what is already there - but letting METHODS trump METHOD when both
>> are specified….  hmm… Might do that.
> 
> Yes, as long as it doesn't break the more "normal" automake way of
> doing things, I really like this idea.

All - 

I've implemented the multiple method functionality.  Take a look at

https://libmesh.svn.sourceforge.net/svnroot/libmesh/branches/libmesh.automake

and let me know what you think.  I've got some polishing to do, but it should 
demonstrate the desired behavior:

$ ./configure --with-methods="opt dbg"
$ ./configure METHODS="devel"

should work as you would expect.  The default is the whole monte - "opt dbg 
devel." Note I still need to clarify METHODS vs. METHOD - for this prototype 
only the former is used, the latter is outright ignored when building libMesh.  
It is still interpreted by libmesh-config and the installed Make.common.

The mechanism to do this is using target-specific flags, which has the 
unfortunate side-effect or target bloat - basically requiring three definitions 
for each target.

for example:

if LIBMESH_DBG_MODE
  lib_LTLIBRARIES            += dbg/libmesh_dbg.la
  dbg_libmesh_dbg_la_SOURCES  = $(libmesh_SOURCES)
  dbg_libmesh_dbg_la_CPPFLAGS = $(CPPFLAGS_DBG) $(AM_CPPFLAGS) 
  dbg_libmesh_dbg_la_CXXFLAGS = $(CXXFLAGS_DBG)
  dbg_libmesh_dbg_la_CFLAGS   = $(CFLAGS_DBG)
  dbg_libmesh_dbg_la_LIBADD   = contrib/libcontrib.la
endif

if LIBMESH_DEVEL_MODE
  lib_LTLIBRARIES                += devel/libmesh_devel.la
  devel_libmesh_devel_la_SOURCES  = $(libmesh_SOURCES)
  devel_libmesh_devel_la_CPPFLAGS = $(CPPFLAGS_DEVEL) $(AM_CPPFLAGS) 
  devel_libmesh_devel_la_CXXFLAGS = $(CXXFLAGS_DEVEL)
  devel_libmesh_devel_la_CFLAGS   = $(CFLAGS_DEVEL)
  devel_libmesh_devel_la_LIBADD   = contrib/libcontrib.la
endif

if LIBMESH_OPT_MODE
  lib_LTLIBRARIES        += opt/libmesh.la
  opt_libmesh_la_SOURCES  = $(libmesh_SOURCES)
  opt_libmesh_la_CPPFLAGS = $(CPPFLAGS_OPT) $(AM_CPPFLAGS) 
  opt_libmesh_la_CXXFLAGS = $(CXXFLAGS_OPT)
  opt_libmesh_la_CFLAGS   = $(CFLAGS_OPT)
  opt_libmesh_la_LIBADD   = contrib/libcontrib.la
endif

In this way, even though each libMesh library depends on the same source files, 
they all get compiled multiple times.

To keep this from getting out of hand, I factored as much commonality into 
examples/Make.common as possible.  Each example then compiles to

example
example-dbg
example-devel 

and 

$ make check 

runs them all.  For examples with multiple steps, each step is run with each 
method before proceeding to the next step.

$ make check METHODS="opt" 

would only run the optimized build.

One thing I'm waffling on is adding a -opt suffix to the executables.  I think 
I might, and then symlink e.g.

meshtool -> meshtool-opt

upon installation.  

Also, potentially the most controversial issue is the contrib stuff.  Because 
of the aforementioned hassle of creating three rules for everything, what I 
have done is set up a single libcontrib.la that only gets compiled *once* - 
with optimized flags - and then included with all three libMesh flavors.  If we 
need debugging information in there it would be straightforward to do that as 
needed with something like

$ ./configure libmesh_CXXFLAGS="-g"

and that will do the trick.  Alternatively I could set up rules to compile 
multiple flavors of everything in contrib too, but I'm not sure its warranted.

-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

Reply via email to