This is one huge vote against this whole thing.
Why are we even doing this? The current build system works great. If we're
going to change it then let's move to a better, newer system.
A LOT of user code is dependent on the libmesh build system. Whatever we
move to it still needs to generate the current makefile.export or something
similar.
Have to list every source file individually? Is this still 1982? I don't
understand how that can be the case. Can we write a script that
autogenerates that list?
Don't fix it if it aint broke. Libmesh is the easiest scientific package to
compile right now... Everyone always talks about how it just works on all
kinds of platforms.... Let's not mess that up.
Derek
Sent from my iPhone
On Jul 3, 2010, at 6:57 AM, "Paul T. Bauman" <[email protected]> wrote:
On Fri, Jul 2, 2010 at 8:54 PM, Kirk, Benjamin (JSC-EG311) <
[email protected]> wrote:
> OK, so I used to hate automake out of ignorance, now I hate it out of
> experience.
>
Agreed on all counts.
>
> Still, that said, it does have some benefits. I think we could take
> advantage of it as a parallel-path build system for a trial period. Before
> I invest any effort in porting, however, I'd like to solicit your thoughts.
>
> Mine:
>
> pros:
> (1) its what people expect
>
Yes.
> (2) make install
>
This is a big deal I think. This would enable having multiple installs of
libMesh sitting around with one source tree and enable developers to monkey
in the code with out breaking the installs. This is a big big plus to me.
> (3) make dist
>
This is handy.
> (4) it 'does the right thing' for shared libraries and makes
> platform-agnostic makefies
>
Usually. I hate libtool more than autoconf and automake combined. I
currently have a problem in my own code where it doesn't do the right thing
for "make check" on Mac, but does on Linux.
>
> cons:
> (1) manually add source files
>
This is actually not as heinous as I originally thought it would be. The leg
work up front is tedious and should be done with beer in hand, but adding
new source files is pretty quick, especially if you organize things.
What is infuriating is handling what gets "installed" and what goes into
"dist". For example, you have to list all .h files to be installed. I
would've liked them to assume that if you want a shared library installed,
you'll want to install all the headers used to build it. Alas, you have to
specify manually. Similarly for dist. Very annoying. Or maybe I'm still too
green with autotools.
(2) verbosity hides compiler warnings, unless using really new versions with
> silent rules
>
I haven't explored too much - are there rules to make things less verbose? I
too am annoyed by my 30 line long compile lines that hide everything when I
do make -j 3.
I volunteer to help with a lot of the leg work on this if it's decided to
move forward with it.
Paul
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
