_symlinks attempts to create multiple symbolic links to .../include

[olaaaf]

When pkg-config returns paths with multiples of .../include the function _symlinks attempts (and fails via java.io.IOException) to create multiple symbolic links of the same path.

To replicate this issue run pkg-config gtkmm-4.0 --cflags --libs

The simplest solution is to modify the name of the final directory that is created. An attempt to create sub-directories to hold these include directories may, in turn, create cyclical symbolic links inside the system directory.

[magreenblatt]

A simple fix is to check if the path exists here before trying to create the symlink:

def _symlinks(ctx, basename, srcpaths):
    result = []
    root = ctx.path("")
    base = root.get_child(basename)
    rootlen = len(str(base)) - len(basename)
    for src in [ctx.path(p) for p in srcpaths]:
        dest = base.get_child(src.basename)
        if not dest.exists:
            ctx.symlink(src, dest)
        result += [str(dest)[rootlen:]]
    return result

[olaaaf]

Sorry I had a pull request ready but removed the forked repo. You can take a look at #3

[dstu]

Another case this fails for is ImageMagick on current Debian unstable:

$ pkg-config ImageMagick --cflags --libs
-I/usr/include/x86_64-linux-gnu/ImageMagick-6 -I/usr/include/ImageMagick-6 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -lMagickCore-6.Q16 

There doesn't appear to be much interest in getting this fixed. Am I mistaken?

[dstu]

I have put together a working implementation of another approach to symlinking in headers. This approach is to create a tree of symlinks that merges include paths together. So, for example, if a package mypackage has include paths /usr/include/mypackage and /usr/include/x86_64-linux-gnu/mypackage, then the contents of those directories will be merged under a common include directory in the Bazel repository that the pkg_config rule generates.

In other words, if our package has headers:

• /usr/include/mypackage/foo/bar.h
• /usr/include/mypackage/foo/baz.h
• /usr/include/x86_64-linux-gnu/foo/quux.h

Then the resulting directory structure will be:

• include/foo/bar.h -> /usr/include/mypackage/foo/bar.h
• include/foo/baz.h -> /usr/include/mypackage/foo/baz.h
• include/foo/quux.h -> /usr/include/mypackage/foo/quux.h

I have implemented this on a branch where I also did a bit of cleanup. I'll open a PR once it is a bit more mature. @cherrry , LMK if you want this factored apart differently (like a distinct PR for cleanup).

This is currently a bit of a hack, because Bazel's lack of while loops and general recursion have kept me from traversing arbitrary directory trees. (Perhaps there is a way to do this that I am not aware of.) I have resorted to unrolling the directory tree traversal manually for several levels.

[cherrry]

Thanks everyone helping here. Unfortunately I haven't work on coding side projects for a while (to completely detach from work 😅), and not actively maintaining the package.

If anyone is interested to maintain a fork, I'm happy to update the README.md to redirect my repository to yours.

But accepting pull requests fixing the issue upstream here isn't feasible since I couldn't help verify the change before merge.

[dstu]

I am very sympathetic to the need to disconnect! Please don't worry about it.

I'd be happy to maintain a fork for the time being. I'm ready to merge my changes into the main branch of my GitHub repo, so just let me know when you think you're done pushing changes on your end, and I'll rebase and keep things moving along.

Feel free to add an AUTHORS file crediting yourself however you'd like. If you don't, I'll add one.