lzo: ensure #include <lzo/lzo1x.h> works with pkgconf cflags -I${includedir}/lzo

[wdconinc]

Downstream packages from lzo, e.g. squashfuse, use #include <lzo/lzo1x.h>, while the lzo2.pc file contains Cflags: -I${includedir}/lzo (no direct link available). These two are not compatible since it leads to a search for lzo/lzo1x.h under <prefix>/include/lzo/ where it does not exist.

Squashfuse doesn't use pkgconf (it uses a custom m4 macro that returns cppflags ending at include/), but packages using pkgconf will run into problems. An example of a package that picks up lzo through pkgconf is cairo, after transition from autotools to meson, in particular when using environments that pull in lzo (since it is not a direct dependency of cairo, but pkgconfig picks up lzo2.pc through the shared view <prefix>/lib/pkgconfig).

This PR adds the recursive link <prefix>/include/lzo/lzo -> <prefix>/include/lzo to ensure that includes will resolve correctly when meson uses pkgconfig to set cflags.

With this PR we get

$ ls -al $(spack location -i lzo)/include/lzo
total 216
drwxr-sr-x 2 wdconinc wdconinc   4096 May 12 19:15 .
drwxr-sr-x 3 wdconinc wdconinc   4096 May 12 19:15 ..
lrwxrwxrwx 1 wdconinc wdconinc      1 May 12 19:15 lzo -> .
-rw-r--r-- 1 wdconinc wdconinc   2638 May 12 19:15 lzo1a.h
-rw-r--r-- 1 wdconinc wdconinc   5387 May 12 19:15 lzo1b.h
-rw-r--r-- 1 wdconinc wdconinc   5384 May 12 19:15 lzo1c.h
-rw-r--r-- 1 wdconinc wdconinc   3073 May 12 19:15 lzo1f.h
-rw-r--r-- 1 wdconinc wdconinc   2634 May 12 19:15 lzo1.h
-rw-r--r-- 1 wdconinc wdconinc   5873 May 12 19:15 lzo1x.h
-rw-r--r-- 1 wdconinc wdconinc   4641 May 12 19:15 lzo1y.h
-rw-r--r-- 1 wdconinc wdconinc   3771 May 12 19:15 lzo1z.h
-rw-r--r-- 1 wdconinc wdconinc   2525 May 12 19:15 lzo2a.h
-rw-r--r-- 1 wdconinc wdconinc   5566 May 12 19:15 lzo_asm.h
-rw-r--r-- 1 wdconinc wdconinc  16006 May 12 19:15 lzoconf.h
-rw-r--r-- 1 wdconinc wdconinc 127289 May 12 19:15 lzodefs.h
-rw-r--r-- 1 wdconinc wdconinc   1823 May 12 19:15 lzoutil.h

[spackbot-app]

Hi @wdconinc! I noticed that the following package(s) don't yet have maintainers:

• lzo

Are you interested in adopting any of these package(s)? If so, simply add the following to the package class:

    maintainers("wdconinc")

If not, could you contact the developers of this package and see if they are interested? You can quickly see who has worked on a package with spack blame:

$ spack blame lzo

Thank you for your help! Please don't add maintainers without their consent.

You don't have to be a Spack expert or package developer in order to be a "maintainer," it just gives us a list of users willing to review PRs or debug issues relating to this package. A package can have multiple maintainers; just add a list of GitHub handles of anyone who wants to volunteer.