install completions in path relative to DESTDIR

[wahjava]

The completions when installed don't respect DESTDIR which requires packagers to patch it downstream who're relying on DESTDIR mechanism, e.g. FreeBSD.

[alerque]

I already reported in #335 and then submitted a PR in #336.

[genivia-inc]

Thank you for your quick feedback! I will take a closer look today to merge and fix the problem. I understand the DESTDIR problem for package distributors, which I had overlooked. I did my best to follow the (somewhat scarce) information I could find on defining the configure scripts and Makefile.am to install completions.

[genivia-inc]

The changes to Makefile.am are fine and already merged. The Makefile.in update is generated with autotools on my end.

[alerque]

Also just a note, the Makefile.in (and configure and a few others) shouldn't actually be tracked at all. They are meant do be in the source dist tarball generated with make dist but not tracked in VCS. If you'd like a PR than fixes this and a few other GNU Autotools snafus I might be able to contribute them at some point.

[genivia-inc]

I know. I just want to keep these things complete, because I've had people complain about missing files in some of my other projects over the past 20+ years, because they didn't understand how autotools work and that these can be generated. Most notable is config.h.in which seems always a "can you send It to me" item, perhaps also because some people do not install autotools. Lesson learned to save my time to spend time on important things: always overdo things.

Your're welcome to share your thoughts, comments and suggestions on the autotool files if they can be improved. I created a whole bunch of m4 files in m4/ to check for compression libraries and PCRE2. Only the m4 ax gzip file was something I found in the GNU docs. It's strange that after so many years that these still aren't widely available. Perhaps use cmake? But that means losing full control and I dislike the syntax and design of it.

[genivia-inc]

I meant to say config.h as an example of "can you send it to me", not config.h.in that is actually used to create config.h. Sigh...

[alerque]

Yes I get the process can be painful. But also some things are more painful than they need to be because the tooling isn't being used as it was designed to be used. End users should not need to install autotools to use an autotools based project, that's part of the design. The generated source tarballs have it all baked in. It doesn't seem like the source tarballs are even usable at this point though.

C.f. #339 and assign me to it if you're interested.