[MacPorts] #48677: kealib @1.4.2.20140825_2: CMake Error: The source directory does not appear to contain CMakeLists.txt
MacPorts
noreply at macports.org
Sat Aug 22 19:04:44 PDT 2015
#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
More information about the macports-tickets
mailing list