[MacPorts] #48677: kealib @1.4.2.20140825_2: CMake Error: The source directory does not appear to contain CMakeLists.txt

[MacPorts]

#48677: kealib @1.4.2.20140825_2: CMake Error: The source directory does not appear
to contain CMakeLists.txt
-----------------------+---------------------
  Reporter:  bmayer@…  |      Owner:  vince@…
      Type:  defect    |     Status:  new
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:  2.3.3
Resolution:            |   Keywords:
      Port:  kealib    |
-----------------------+---------------------

Comment (by ryandesign@…):

 Upon further investigation, I see that the portgroup also uses
 ${worksrcpath} as the default configure.post_args. So the portgroup really
 wants worksrcpath to be the source directory—the one containing
 CMakeLists.txt. MacPorts doesn't have a variable that means "the directory
 that actually contains the source code" (worksrcpath is meant to mean
 that, but really just means the top level directory that was extracted) so
 we may have to change the port to match the portgroup's expectation. It
 has been months since this change was made in the portgroup, so there must
 not be that many ports affected by this problem, so it's not too awful to
 have to change these few ports.

 There are probably other ports that set configure.dir and build.dir
 instead of setting worksrcpath; I remember doing this in quite a few ports
 (though I don't remember if they also use the cmake portgroup). There are
 times when it is advantageous for worksrcpath to remain pointing to the
 top level directory, while setting configure.dir and build.dir to a
 subdirectory. Using kealib as an example, its top level directory contains
 "README.md" and "trunk". "trunk" is the directory that contains the source
 code, but if we set worksrcpath to ${worksrcpath}/trunk, that would also
 become the default patch.dir which would prevent us from being able to
 apply a patch to README.md, which is something we might want to do (if not
 in this port, then in other ports). (Patchfiles used to be able to specify
 that the file to be patched is in a parent directory, but the version of
 the patch command included with OS X 10.6.8 and later prohibits this; see
 #30034 for an example of this problem.) However, a workaround for that
 would be to set patch.dir back to the top level directory. So, although I
 thought this was a problem when I started writing this paragraph, I guess
 it actually isn't.

-- 
Ticket URL: <https://trac.macports.org/ticket/48677#comment:3>
MacPorts <https://www.macports.org/>
Ports system for OS X