[ET Trac] [Einstein Toolkit] #1661: ExternalLibraries/PAPI does not build with gcc 4.8.2
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Mon Sep 29 12:30:30 CDT 2014
#1661: ExternalLibraries/PAPI does not build with gcc 4.8.2
------------------------------------+---------------------------------------
Reporter: tbode | Owner: tbode
Type: defect | Status: new
Priority: major | Milestone: ET_2014_11
Component: EinsteinToolkit thorn | Version: development version
Resolution: | Keywords: PAPI
------------------------------------+---------------------------------------
Comment (by rhaas):
Well I did not want to step on anyone's toes. :-).
I don't do (a) of course. I tend to iterate between compiling, fixing the
compiler reported errors and compile again until the code compiles (ie the
same procedure as when fixing code of my own). Then I do a diff between
the original version and the fixed one. So it's more like (b) but with a
manual fix rather than constructing a perl regex which I have to test and
verify by doing a diff to see what it actually changed.
I agree that for this change (removing -Werror) the perl script is shorter
and not more complex than the patch. Pelr "wins" when the number of
affected files is large and the replacement is simple. Perl **may** affect
innocent files (eg changelogs) but no one should (have to) look at those
files. It also means that there are potentially multiple locations to
check for "patches" namely the configure script for the perl call and the
dist directory for more complex changes.
Just as long we don't try to do what
http://svn.cactuscode.org/projects/ExternalLibraries/LORENE/trunk/dist/check_fopen_error.patch
does in perl, I am happy.
For many tools, but in particular with perl I would rather not want use
shortness of the script as a measure for its simplicity :-). For example
the perl scrip used
{{{
perl -pi -e 's/malloc.h/stdlib.h/'
}}}
contains a (most likely never triggered) bug since {{{.}}} is not properly
escape inside of the regex. It should be
{{{
perl -pi -e 's/malloc\.h/stdlib\.h/'
}}}
or any amount of extra complication if there'd ever by something like
"mymalloc.h" if one would want to be pedantic.
So: the perl solution is fine with me, but I do reserver the right to
complain again if the perl expressions become truly complex.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1661#comment:5>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
More information about the Trac
mailing list