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