From: Cody P. <cod...@gm...> - 2012-10-04 21:28:24
|
So I went through the process of updating Fparser today (Version 4.3.3 -> 4.5) in an attempt to figure out why our compiler stack wouldn't compile it in debug mode. I have successfully tested this update on Linux/GNU, OS X/Apple-GCC, and OS X/Clang without any issues. It's a somewhat painstaking process since the Makefile in libMesh was extensively modified but I believe that I have preserved all of the existing behavior properly. On a side note, I still can't compile it in debug mode but that's besides the point. The patch is way to big to attach here, but are there any comments before I commit to trunk? Thanks, Cody |
From: Roy S. <roy...@ic...> - 2012-10-04 22:06:19
|
On Thu, 4 Oct 2012, Cody Permann wrote: > The patch is way to big to attach here, but are there any comments > before I commit to trunk? For anyone else who's curious, I had Cody send me a copy you could look over here: http://users.ices.utexas.edu/~roystgnr/0001-Fparser-Update.patch No obvious flaws (other than the pre-existing "why do those .inc files have to be in svn, again?") I can see. --- Roy |
From: Cody P. <cod...@gm...> - 2012-10-04 22:11:02
|
On Thu, Oct 4, 2012 at 4:06 PM, Roy Stogner <roy...@ic...>wrote: > > On Thu, 4 Oct 2012, Cody Permann wrote: > > The patch is way to big to attach here, but are there any comments >> before I commit to trunk? >> > > For anyone else who's curious, I had Cody send me a copy you could > look over here: > > http://users.ices.utexas.edu/~**roystgnr/0001-Fparser-Update.**patch<http://users.ices.utexas.edu/~roystgnr/0001-Fparser-Update.patch> > > No obvious flaws (other than the pre-existing "why do those .inc files > have to be in svn, again?") I can see. > There's only one inc file in there, and I don't believe that we need it. I only added it to the patch because it's already in there! Cody > --- > Roy > |
From: Cody P. <cod...@gm...> - 2012-10-04 22:13:57
|
On Thu, Oct 4, 2012 at 4:10 PM, Cody Permann <cod...@gm...> wrote: > > > On Thu, Oct 4, 2012 at 4:06 PM, Roy Stogner <roy...@ic...>wrote: > >> >> On Thu, 4 Oct 2012, Cody Permann wrote: >> >> The patch is way to big to attach here, but are there any comments >>> before I commit to trunk? >>> >> >> For anyone else who's curious, I had Cody send me a copy you could >> look over here: >> >> http://users.ices.utexas.edu/~**roystgnr/0001-Fparser-Update.**patch<http://users.ices.utexas.edu/~roystgnr/0001-Fparser-Update.patch> >> >> No obvious flaws (other than the pre-existing "why do those .inc files >> have to be in svn, again?") I can see. >> > > There's only one inc file in there, and I don't believe that we need it. > I only added it to the patch because it's already in there! > Cody > Ok - I lied, two, and they probably both can be removed. > > >> --- >> Roy >> > > |
From: Roy S. <roy...@ic...> - 2012-10-04 22:28:48
|
On Thu, 4 Oct 2012, Cody Permann wrote: > Ok - I lied, two, and they probably both can be removed. One can't be removed without either breaking stuff or writing our own Makefile entries to handle what the original author presumably does by hand. The other, I'm not sure what it's for, but I'd rather not remove it either. I think forking contrib/ code is justified when doing so is necessary to get it to compile or play nicely with our configuration options, not so much when it's just a matter of aesthetics. Matters of aesthetics in contrib/ code merely justify me whining on the mailing lists. --- Roy |
From: Cody P. <cod...@gm...> - 2012-10-04 22:35:47
|
On Thu, Oct 4, 2012 at 3:28 PM, Cody Permann <cod...@gm...> wrote: > So I went through the process of updating Fparser today (Version 4.3.3 -> > 4.5) in an attempt to figure out why our compiler stack wouldn't compile it > in debug mode. I have successfully tested this update on Linux/GNU, OS > X/Apple-GCC, and OS X/Clang without any issues. It's a somewhat > painstaking process since the Makefile in libMesh was extensively modified > but I believe that I have preserved all of the existing behavior properly. > On a side note, I still can't compile it in debug mode but that's besides > the point. ... and in other news - we finally located the cause of the problem with my debug builds earlier today. Somehow our tech managed to provide a bad configure line to Petsc that only corrupted the ability of my compiler to produce a working debug build of libMesh. I know this doesn't make sense but he was able to reconfigure/rebuild Petsc and the problem magically disappeared in libMesh. One of those truly, "WTH" moments... Oh well, I guess if the fparser patch goes in, at least I accomplished something... > > The patch is way to big to attach here, but are there any comments before > I commit to trunk? > > Thanks, > Cody > |