Might be good if we have one page document with the release notes on the
new build system ? It can include the simplest, most straightforward way of
getting libMesh up and running as before. And then it can also include the
newer features of the system and how they can be useful.
Just think a separate document might make things clearer for users. Once
they get comfortable with libMesh up and running, they can start exploring
the new options.
On Sat, Nov 24, 2012 at 11:41 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> On Nov 21, 2012, at 8:07 PM, Paul T. Bauman <ptbau...@gmail.com> wrote:
>
> > The only difference between this and the former build system is the
> extra cd's (minor annoyance) and make install (nice new feature, IMHO, that
> was not present in the previous build system).
> >
> >> Then I go make a change to libMesh and need to do:
> >>
> >> cd build_opt
> >> make
> >> make install
> >> cd ..
> >> cd build_dbg
> >> export METHOD=dbg
> >> make
> >> make install
> >>
> >> Every single change I must now go into two different directories to
> build AND I must run "make install" for each one.
>
>
> Of course, you can always omit the naked make -- make install will run it
> for you. Also, the only time METHOD is actually used is configure time.
> That is why it is difficult to support dynamic METHODs - the Makefile
> targets must not depend on environment variables.
>
> Now, as I mentioned previously, if your workflow always considers multiple
> methods it is pretty straightforward for me to add support for
>
> $ ./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.
>
> About the compile times on NFS-mounted systems: The dependency generation
> is now much more rigorous than what we had previously. Before we relied on
>
> #include "foo.h"
> #include <bar.h>
>
> as being different, and only considered "foo.h" as a dependency. Provided
> people followed the convention (usually did, although I've fixed this
> countless times) it was reasonable. This has undoubtedly missed
> system-level dependencies that should have been caught.
>
> We now get all system dependencies, including things like cmath, and I'm
> sure this takes longer on NFS-mounted directories.
>
> If you are doing a "one-time-build" on a system and you are compiling
> everything from scratch you can forego all dependency generation with
>
> $ ./configure --disable-dependency-tracking …
>
> which will just compile everything.
>
> -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
>
--
Vikram Garg
Postdoctoral Associate
Center for Computational Engineering
Massachusetts Institute of Technology
http://www.runforindia.org/runners/vikramg
------------------------------------------------------------------------------
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
