Ok. No one tells me how it works on all kinds of platforms, but I guess the
fact they don't say it doesn't work is a good thing!
On Jul 3, 2010, at 9:54 AM, "Derek Gaston"
<[email protected]<mailto:[email protected]>> wrote:
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"
<<mailto:[email protected]>[email protected]<mailto:[email protected]>>
wrote:
On Fri, Jul 2, 2010 at 8:54 PM, Kirk, Benjamin (JSC-EG311)
<<mailto:[email protected]><mailto:[email protected]>[email protected]<mailto:[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 <http://SF.net> SF.net<http://SF.net> email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit <http://sprint.com/first> sprint.com/first<http://sprint.com/first> --
<http://p.sf.net/sfu/sprint-com-first> <http://p.sf.net/sfu/sprint-com-first>
http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Libmesh-devel mailing list
<mailto:[email protected]>[email protected]<mailto:[email protected]>
<https://lists.sourceforge.net/lists/listinfo/libmesh-devel>https://lists.sourceforge.net/lists/listinfo/libmesh-devel
<ATT00001..txt>
<ATT00002..txt>
------------------------------------------------------------------------------
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
