gdal-bash-completion.sh installs in the wrong directory

[Kurt Schwehr]

Occurs in 2.1 and trunk

For things like fink, the install in scripts/GNUMakefile does the wrong thing. Note the double /sw at the front of this:

/sw/sw/etc/bash_completion.d/gdal-bash-completion.sh

With fink, the package is installed into a temporary location to construct the deb and the deb tools do the install. So it's installing not in the install directory and there is an extra prefix

Using pkg-config directly, does the wrong thing.

This line

cp gdal-bash-completion.sh $(DESTDIR)${prefix}`pkg-config --variable=compatdir bash-completion`;

is not going to work like the rest of the installs

pkg-config --variable=compatdir bash-completion
/sw/etc/bash_completion.d

I don't think this is the quite the correct fix:

cp gdal-bash-completion.sh $(INSTDIR)`pkg-config --variable=compatdir bash-completion`;

In addition to the above, I think the result from pkg-config needs to have the DESTDIR stripped off it.

[dmacks]

The original

$(DESTDIR)${prefix}`pkg-config --variable=compatdir bash-completion`;

is logically flawed. Bash publishes exactly where it will look, and has no way to know it should look in that location as a subdir arbitrarily set for some third-party's world. But we also can't assume that bash and gdal will have the same prefix. Instead, just using whatever bash says, but put under DESTDIR (not INSTDIR) is probably what should happen. Testing...

[dmacks]

Use DESTDIR instead of DESTDIR/prefix

[Even Rouault]

In 35060:

scripts/GNUmakefile: fix installation of gdal-bash-completion.sh (patch by dmacks, fixes #6607)

[Even Rouault]

r35061 "scripts/GNUmakefile: revert r35060. This breaks './configure --prefix=$HOME/my-install; make install' (ref #6607)"

[opoplawski]

Some comments:

• I would install with:

  $(INSTALL_DATA) gdal-bash-completion.sh $(DESTDIR)`pkg-config --variable=compatdir bash-completion`/gdal
  

as this will preserve timestamps and name the file more appropriately.

• I'm not sure why you think this breaks the --prefix install mode - assuming bash-completion is a system install, it will only look for completion files in the system location.

[Even Rouault]

• I'm not sure why you think this breaks the --prefix install mode - assuming bash-completion is a system install, it will only look for completion files in the system location.

I'm not "assuming" it breaks. I've tested it on Ubuntu 14.04 and it does break "make install" without root priviledge. Perhaps I should play with make install DESTDIR= instead, hum.

[opoplawski]

Ah, hadn't thought about that case. I guess making the rule fail gracefully without aborting make would be one possibly. Or shifting to install into $prefix/completions.d/, but that would not be useful without hacking bash-completion.

[Kurt Schwehr]

We need to install it not in $prefix. Packagers have to build a tree off to the side so that things like the Debian apt packager can see the whole tree and turn it into an installable ball-o-stuff. Sorry I haven't looked at it more yet. I triggered this bug by upgrading GDAL on fink.

[dmacks]

Replying to rouault:

• I'm not sure why you think this breaks the --prefix install mode - assuming bash-completion is a system install, it will only look for completion files in the system location.

I'm not "assuming" it breaks. I've tested it on Ubuntu 14.04 and it does break "make install" without root priviledge. Perhaps I should play with make install DESTDIR= instead, hum.

Are you trying to install it in a Debian-esque staging area for later (as root) copying to the live system? That's exactly DESTDIR's role. But if you're installing in truely in user-land, then there's no way the bash-completion thing could work normally because the current logic is to install it *where bash-completion says it will look for it*, which would be a root area. Maybe we should have this path set as a variable, which defaults to "wherever bash says*, but that could be overridden by users wishing to stash it somewhere else (for example, who have a bash that knows to look somewhere other than where .pc says).

[ryandesign]

Replying to rouault:

In 35060:

scripts/GNUmakefile: fix installation of gdal-bash-completion.sh (patch by dmacks, fixes #6607)

FYI we're using this patch to fix this problem in MacPorts now; see ​https://trac.macports.org/ticket/51989.

[Kurt Schwehr]

For reference, so folks don't have to go to github, the macports patch:

GNUmakefile

@@ -5 +5 @@
 
 install:
         if test "x`pkg-config --version 2>/dev/null`" != "x" -a "x`pkg-config --variable=compatdir bash-completion`" != "x"; then \
-                $(INSTALL_DIR) $(DESTDIR)${prefix}`pkg-config --variable=compatdir bash-completion` ; \
-                cp gdal-bash-completion.sh $(DESTDIR)${prefix}`pkg-config --variable=compatdir bash-completion`; \
+                $(INSTALL_DIR) $(DESTDIR)`pkg-config --variable=compatdir bash-completion` ; \
+                cp gdal-bash-completion.sh $(DESTDIR)`pkg-config --variable=compatdir bash-completion`; \
         fi

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.