This coming along quite nicely I think. My last step is to clean out the
Make.common definitions and then test including it in client projects. I
started on that over the weekend and don't see any issues with maintaining that
functionality.
The biggest changes from the developer's perspective will be
(1) files must manually be added to ./Makefile.am and ./include/Makefile.am
(2) METHOD is now a configure-time variable. Multiple build methods are still
supported and are properly installed into different paths, but must be built
from different directories. For example, I handle it like this:
$ ./bootstrap
$ mkdir $METHOD
$ cd $METHOD
$ ../configure ...
As part of this process I have also cleaned up almost all of our M4 sources for
consistency and brevity. I recognize that automake is a big stepfunction in
our build process, but I think this will make long-term maintenance a lot
easier.
If anyone is feeling adventurous give ^/branches/libmesh.automake a whirl:
$ svn co
https://libmesh.svn.sourceforge.net/svnroot/libmesh/branches/libmesh.automake
$ cd libmesh.automake
$ ./bootstrap
$ ./configure --with-method=devel --prefix=/tmp/foo
$ make -j 18
$ make -j 18 check
$ make install
$ make installcheck
$ make -j 18 distcheck
Roy - a long time ago you hoped using automake might help with IDE integration
- is that something you are still interested in, and if so might you check it
out?
-Ben
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
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-dev2
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
