Firstly… I'm still against this idea. I think it's adding complication to
something that currently works well for the majority of users and use cases.
On Mar 5, 2012, at 11:16 AM, Kirk, Benjamin (JSC-EG311) wrote:
> (1) files must manually be added to ./Makefile.am and ./include/Makefile.am
For me, this would be a no go. Surely there is a a way to do this
automatically. This just doesn't make sense.
> (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 …
This is really bad… I can't even see having to explain this to our users. They
just barely get the current METHOD=dbg stuff… but now there are different
directories? Not only that but do you have to do a make install? How does
LIBMESH_DIR work now?? Does it point to the build directory, to the install
directory or to the source directory? Do you have to change it all the time to
switch between METHOD's?
Maybe there is something I haven't explained yet: Our users have to rebuild
libMesh quite often. We make backwards incompatible changes to libMesh and
MOOSE… and it forces our users to need to rebuild libMesh. This isn't the type
of thing where they do it once and then they can "make install" that version
and use it for a long time. Adding complication to the libMesh rebuild process
is bad. Bad enough that with this talk of using Automake we've started talking
about meta-tools to build libMesh so we can insulate them from it… which is
dumb because the current build system is good and simple enough that we don't
need to do that...
> 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
The ./boostrap is only temporary right? Users won't have to do that once we
check in bootstrapped configure / makefiles right?
Is "make install" optional or not?
I'm sorry to sound so negative. I realize you've put a lot of time into this…
but as far as I can tell you've made one small situation somewhat easier
(multiple out of directory builds on different machines sharing the same
directory) and everything else has become more complicated…
It feels like optimizing for developers and making users lives more
complicated…. which is really the opposite of what we should be doing.
I'll still check it out and see what's what (it will probably answer a lot of
my questions). I'll respond back after I've done that.
Derek
------------------------------------------------------------------------------
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
