Include file clobbering / Reinplace strange behavior
Vincent Habchi
vince at macports.org
Sat Oct 4 06:13:58 PDT 2014
Guys,
I’m writing an updating port for the new version of gis/gdal.
However, the port does not compile because a .h file installed by the old version into ${prefix}/include masks a new version of the same .h bundled with the newest source.
So question 1: is there a standard workaround to address this problem?
I know the cleanest way is to switch the -I flags order so that the local include repertory is placed before ${prefix}/include on the compiler line invocation. However, that’s a pain to implement.
So, I decided to copy the culprit .h file, giving the copy a slightly different name, then change all #include to this new name. Finally, I use find(1) to locate every relevant file like this:
post-extract {
file copy ${worksrcpath}/port/cpl_port.h ${worksrcpath}/port/Cpl_port.h
set files_to_patch [exec find ${worksrcpath} -type f -exec grep -l "cpl_port.h" \{\} \;]
foreach file ${files_to_patch} {
# DEBUG
puts ${file}
reinplace "s|cpl_port.h|Cpl_port.h|" ${file}
}
}
However, the procedure fails at a certain point for an unknown reason:
/opt/…/frmts/grib/degrib18/degrib/grib2api.c
/opt/…/frmts/grib/degrib18/degrib/inventory.cpp
/opt/…/frmts/grib/degrib18/degrib/memendian.h
/opt/…/frmts/grib/degrib18/degrib/metaname.cpp
sed: RE error: illegal byte sequence
So it works fine (I peeked inside the printed files and the substitution has correctly been made) with ten or twenty files, then it suddenly breaks on a mundane file.
Question 2: Does anyone have a clue why?
Thanks!
Vincent
More information about the macports-dev
mailing list