Propose removing dist_docs/* - is burnpath really needed?

[Kurt Schwehr]

Do we still have a usecase for pszUpdatableINST_DATA in gdaldrivermanager.cpp? It appears to me that any situation that burnpath could be used to modify an existing shared or static binary object could be easily replaces by recompiling with INST_DATA defined pointing to the new location. It does not appear that burnpath or INST_DATA_TARGET is in active use in the source tree.

If this functionality is critical someplace, we should document that in gdaldrivermanager.cpp.

burnpath came in with r3234.

find . -type f | grep -v svn | xargs egrep 'dist_docs|burnpath|install_unx.sh|SETUP_GDAL.BAT' | grep -v /dist_docs/
./makegdal_gen.bat:    for %%d in (data debian dist_docs docs html m4 pymod swig vb6) do (
./mkbindist.sh:cp dist_docs/README_UNX_BIN.TXT $DIST_DIR
./mkbindist.sh:cp dist_docs/install_unx.sh $DIST_DIR
./mkbindist.sh:cc -o $DIST_DIR/bin/burnpath dist_docs/burnpath.c
./mkgdaldist.sh:rm -rf gdal/dist_docs
./PROVENANCE.TXT:=== gdal/dist_docs ===

Patching binaries seems to be playing with fire.

[warmerdam]

I would not be offended by the removal of pszUpdableINST_DATA. I am not aware of anything that uses it currently.

I think I did use it for FWTools on linux, so update the paths at installation time without recompiling. But I don't imagine any normal packaging systems require this.

[Kurt Schwehr]

r30899 in trunk

[Mateusz Łoskot]

r37381 - Remove dist_docs folder (dangling empty after r30899)