#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