On Mon, 22 Oct 2012, Cody Permann wrote:

> On Sat, Oct 20, 2012 at 9:56 AM, Kirk, Benjamin (JSC-EG311) 
<benjamin.kir...@nasa.gov> wrote:

> I'll let Roy weigh in, but my observation has been that 90% of the
> current build requirements are to make the source
> compressor/obfuscator that in the end produces a single source
> file… and a lot of the compiler issues I've seen are with actually
> the compressor, not fparser itself.

Roy, any thoughts on this or are we crazy here at the INL?  I'm
willing to prepare a patch to go back to the release version of the
package or perhaps we could do something in between.  Maybe
"--enable-fparser-devel" and have it default to disabled bringing in
only the release files for
normal builds.

IIRC when I added fparser what I grabbed was the release version at
the time (4.3?) - I've certainly got no need for any newer features
myself, and based on the amount of futzing I had to do to get it to
build properly with our system I'd need some significant incentives
before I'd want to spend time tracking a non-release version.  My vote
for "something in between" would just be the 4.5 release itself,
unless there's any known bugs that have been fixed in the devel
snapshots but not wrapped up in a stable release yet.
---
Roy
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to