[MacPorts] #60366: liblas: Duplicate -DCMAKE_INSTALL_NAME_DIR=${prefix}/lib flag and reintroduction of rpath

[MacPorts]

#60366: liblas: Duplicate -DCMAKE_INSTALL_NAME_DIR=${prefix}/lib flag and
reintroduction of rpath
-------------------------+--------------------
  Reporter:  ryandesign  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.6.2
Resolution:              |   Keywords:
      Port:  liblas      |
-------------------------+--------------------

Comment (by ryandesign):

 Replying to [comment:2 mathstuf]:
 > Ah, I didn't see that it was already there. Mainly because the install
 > name should be `$prefix/lib` with this patch, not @rpath as you're
 > seeing.

 It seems pretty clear that it's the liblas CMakeLists.txt that's causing
 this to happen, with this block:

 {{{
 if (APPLE)
   set_target_properties(
     las_c
     PROPERTIES
     INSTALL_NAME_DIR "@rpath" BUILD_WITH_INSTALL_RPATH ON)
   set_target_properties(
     las
     PROPERTIES
     INSTALL_NAME_DIR "@rpath" BUILD_WITH_INSTALL_RPATH ON)
 endif()
 }}}

 If we don't want rpaths, and I would argue that we don't, then I would
 suggest trying to remove that block.


 > I'm pretty sure I had absolute paths in my library IDs when I
 > tested it locally, but maybe that wasn't true after the rebase.

 Per Mojca's comment in the PR, you had not initially increased the
 revision. Is it possible that when you reinstalled the port you received a
 binary of the existing version, rather than building your locally changed
 version?


 > The main issue with @rpath is that an `-Wl,-rpath,$dir` needs added to
 > all linking executables in order to find any libraries using @rpath.
 > CMake doesn't do this today (mainly because it doesn't know which
 > linked-to libraries are using @rpath or how deep they expect to be from
 > there). For example, Qt frameworks use `@rpath/QtCore.framework/QtCore`,
 > so you need to go up 2 directories to get the proper rpath entry for
 > that.

 Exactly. That's why the code that you removed from the port was in there
 -- to remove the use of rpath.


 > > Because the install name of the libraries has changed, all
 > > programs/libraries that link with this library must be revbumped to
 use
 > > the new install name.
 >
 > Technically, no. The library ID is copied at link time into the
 > consuming executable. But I can see the argument for consistency. So the
 > old path is still used to look up the current libraries.

 What I am saying is that by making this change to liblas, you have changed
 how other ports would build if they were to be rebuilt. And that is
 sufficient reason to force those other ports to be rebuilt by increasing
 their revision. We want RepeatableBuilds.

 However since it appears that reintroducing the use of rpath was not your
 intent, we should fix it so that rpath is once again not used (which will
 need another revision increase for liblas) and then revbump the ports that
 use the library.


 > The reason this came to my attention is because the manual patching was
 > not correct on a machine I was working on (the symlink name was used in
 > the ID, not the actual library).

 I agree, the difference in versioning between the symlink and the library
 was confusing, but it would not be the first time I've seen a project get
 their library versioning wildly wrong. I don't know at this point whether
 that wrongness came from the liblas project or from the portfile additions
 in this case.

-- 
Ticket URL: <https://trac.macports.org/ticket/60366#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS