CGALConfig.cmake does not correctly handle /lib -> /usr/lib symlink

[scgtrp]

Issue Details

I'm on Arch, which does not use a separate /usr partition and replaces /lib with a symlink to /usr/lib.

I'm trying to compile OpenSCAD. It finds CGAL's cmake configuration at /lib/cmake/CGAL/CGALConfig.cmake. Then:

• get_filename_component(CGAL_CONFIG_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH) sets CGAL_CONFIG_DIR=/lib/cmake/CGAL
• the chain of get_filename_component(CGAL_ROOT "${CGAL_ROOT}" DIRECTORY) calls sets CGAL_ROOT=/
• CGAL_FOUND is set by testing for the existence of /include/CGAL/config.h, which does not exist because /include isn't a thing
• and OpenSCAD's build incorrectly complains that I don't have CGAL installed.

My CGAL installation otherwise seems fine; bodging it with

get_filename_component(CGAL_CONFIG_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
set(CGAL_CONFIG_DIR "/usr${CGAL_CONFIG_DIR}")

is enough to allow the build to succeed.

Environment

• Operating system: Arch Linux, amd64
  • Arch does not appear to make any changes to the upstream cmake files.
• Compiler: gcc 14.2.1
• Release or debug mode:
• Specific flags used (if any):
• CGAL version: 6.0
• Boost version: 1.86.0
• Other libraries versions if used (Eigen, TBB, etc.):

[mglisse]

Any idea why cmake looks for the file in /lib/cmake and not the equivalent and more canonical /usr/lib/cmake? On a debian system with the same /lib -> /usr/lib symlink, I do get a path starting with /usr/lib. Maybe something in your environment, or a strange cmake config in arch?
I am unsure what the implication would be of adding REALPATH to one of the get_filename_component.

[scgtrp]

That's an excellent question. I don't know cmake well enough to answer it for sure.

OpenSCAD CMakeLists.txt does: find_package(CGAL REQUIRED COMPONENTS Core)

Going down the list of environment variables here (ctrl-F "The set of installation prefixes is constructed using the following steps.")

• CMAKE_PREFIX_PATH, CMAKE_FRAMEWORK_PATH, CMAKE_APPBUNDLE_PATH are unset/empty
• CGAL_DIR is empty on initial cmake run, /lib/cmake/CGAL on reruns on the same build dir
• $PATH is /bin:/sbin:/usr/local/bin:/home/emily/.bin
• CMAKE_SYSTEM_PREFIX_PATH is /usr/local;/usr;/;/usr;/usr/local;/usr/X11R6;/usr/pkg;/opt
  • no, I do not actually have a /usr/X11R6, but good to know cmake has my back if I ever add one
• CMAKE_SYSTEM_FRAMEWORK_PATH, CMAKE_SYSTEM_APPBUNDLE_PATH are unset

($PATH is my shell $PATH; all others checked by inserting message("var=${var}") right above the find_package call in the openscad CMakeLists.txt. I have no $CMAKE_* or $CGAL_* set in my environment.)

I did see the "Path entries ending in /bin or /sbin are automatically converted to their parent directories" bit in the cmake manual. I tried reverting my bodge and doing PATH=/usr/bin cmake -B build but this still failed complaining about the one in /lib.

Happy to dig into other things if you have ideas for where to look.

[mglisse]

When you tried again using a PATH that has /usr/bin before (or instead of) /bin, was it with a clean directory, or did it have remnants of previous tries?
I can indeed reproduce the issue if I make my PATH start with /bin. This looks like an unintended consequence of the links to /usr, I think it would make sense for cmake itself to deal with it (either upstream or in distribution-specific patches) by replacing / with /usr as a prefix candidate when /lib is a symlink to /usr/lib.

[scgtrp]

When you tried again using a PATH that has /usr/bin before (or instead of) /bin, was it with a clean directory, or did it have remnants of previous tries?

I thought I was in a clean directory, but perhaps not. I just tried PATH=/usr/bin cmake -B build again after removing build for real this time, and it worked. So yeah, looks like it's picking it up from $PATH.

[lrineau]

So, eventually, @scgtrp, do you still think that is a bug from CGAL?

[scgtrp]

That's kind of a philosophical categorization problem, ne?

I can see an argument where it's CGAL's problem (should be doing realpath before doing path manipulations), or cmake's problem (shouldn't do sketchy manipulations on $PATH to generate cmake search paths, or should at least add a hack for the common merged / + /usr case as @mglisse suggested), or even the distros' problem (should set CMAKE_PREFIX_PATHS somewhere, or should have just deleted /usr and moved its contents into / instead of setting up a situation where most, but not all, system files are accessible at two different locations).

As a developer, I'd just hack it with realpath on the CGAL side and be done with it while grumbling about the other things. If I knew cmake upstream to be receptive to such changes (I've never dealt with them myself), I'd suggest it to them in parallel, but otherwise probably wouldn't bother.

As an end user, I don't care, I just want the thing to work without making me debug cmake scripts.

[lrineau]

That seems fine. I think I agree with you, but I am busy on other things.

@scgtrp @mglisse Does any of you has a patch we can commit? Maybe a pull-request?

[lrineau]

After two weeks, I am still recovering from the rush.

@scgtrp @mglisse Does any of you has a patch we can commit? Maybe a pull-request?

Can you re-summarize the issue and the proposed solution?