From: Kirk, B. (JSC-EG311) <ben...@na...> - 2010-07-03 14:58:22
|
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" <fri...@gm...<mailto:fri...@gm...>> 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:ptb...@gm...>ptb...@gm...<mailto:ptb...@gm...>> wrote: On Fri, Jul 2, 2010 at 8:54 PM, Kirk, Benjamin (JSC-EG311) <<mailto:ben...@na...><mailto:ben...@na...>ben...@na...<mailto:ben...@na...>> 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:Lib...@li...>Lib...@li...<mailto:Lib...@li...> <https://lists.sourceforge.net/lists/listinfo/libmesh-devel>https://lists.sourceforge.net/lists/listinfo/libmesh-devel <ATT00001..txt> <ATT00002..txt> |