cmake @3.24.3 - patch does not work - attempts to patch an empty directory

[snowflake (Dave Evans)]

sudo port patch cmake does not work. It attempts to patch an empty directory. This is odd, as it worked last week. It may be related to using the latest macports-base checkout.

This happens on both El Capitan and Monterey.

Checkouts:

[ffdb7d9ee9e59e9d69a2f29ac08dfd5090f84759/macports-base] (version 2.8.99)

[0cc71e8df56f9a4aa28ec508d45169cde759c00e/macports-ports]

sudo port clean cmake
sudo port extract cmake
cd $(port work cmake)
ls
cmake-v3.24.3-c974557598645360fbabac71352b083117e3cc17
sudo port -d patch cmake
ls
cmake-3.24.3
cmake-v3.24.3-c974557598645360fbabac71352b083117e3cc17

The directory with the short name, which has now appeared, is empty.

Here's a partial listing of the log. It's applying the patch to the empty directory and failing:

Executing:  cd "/opt/local/var/macports/build/_Users_davidevans_macports_sources_github.com_macports_macports-ports_devel_cmake/cmake/work/cmake-3.24.3" && /usr/bin/patch -p0 < '/Users/davidevans/macports/sources/github.com/macports/macports-ports/devel/cmake/files/patch-Modules-noArchCheck.diff'
DEBUG: system:  cd "/opt/local/var/macports/build/_Users_davidevans_macports_sources_github.com_macports_macports-ports_devel_cmake/cmake/work/cmake-3.24.3" && /usr/bin/patch -p0 < '/Users/davidevans/macports/sources/github.com/macports/macports-ports/devel/cmake/files/patch-Modules-noArchCheck.diff'
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- Modules/BasicConfigVersion-AnyNewerVersion.cmake.in.orig
|+++ Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 21
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- Modules/BasicConfigVersion-ExactVersion.cmake.in.orig
|+++ Modules/BasicConfigVersion-ExactVersion.cmake.in
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 39
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- Modules/BasicConfigVersion-SameMajorVersion.cmake.in.orig
|+++ Modules/BasicConfigVersion-SameMajorVersion.cmake.in
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 57
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- Modules/BasicConfigVersion-SameMinorVersion.cmake.in.orig
|+++ Modules/BasicConfigVersion-SameMinorVersion.cmake.in
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored
Command failed:  cd "/opt/local/var/macports/build/_Users_davidevans_macports_sources_github.com_macports_macports-ports_devel_cmake/cmake/work/cmake-3.24.3" && /usr/bin/patch -p0 < '/Users/davidevans/macports/sources/github.com/macports/macports-ports/devel/cmake/files/patch-Modules-noArchCheck.diff'
Exit code: 1
Error: Failed to patch cmake: command execution failed
DEBUG: Error code: CHILDSTATUS 62912 1

[michaelld (Michael Dickens)]

Works for me on the following:

• Port version 2.8.0-99-20221129-01-3d9856bc / macOS version 11.7.2 20G1008 Intel / Xcode version 12.3 12C33
• Port version 2.8.0-99-20221116-01-887b2fb9 / macOS version 11.7.2 20G1011 ARM64 / Xcode version 13.2.1 13C100
• Port version 2.8.0-99-20221116-01-887b2fb9 / macOS version 13.1 22C5059b / Xcode version 14.1 14B47b

I will update one of these to the latest BASE code & see what happens

[michaelld (Michael Dickens)]

Yup I see this issue too with the latest BASE HEAD .. across the board, not just a specific OS / Xcode version

[michaelld (Michael Dickens)]

ah ... guessing it's a default patch level setting

[michaelld (Michael Dickens)]

or not ... that's correct ...hmmm ... strange !!!

[michaelld (Michael Dickens)]

ah ... looks like the link from short WORKSRCDIR to long isn't working ...

$ pwd
/opt/local/var/macports/build/_opt_sources_MacPorts_ports_github_macports_devel_cmake/cmake/work
 ll
total 8
drwxrwxrwx   2 macports  admin   64 Dec  7 14:34 .home/
-rw-rw-rw-   1 macports  admin  192 Dec  7 14:34 .macports.cmake.state
drwxrwxrwx   2 macports  admin   64 Dec  7 14:34 .tmp/
drwxrwxrwx   2 macports  admin   64 Dec  7 14:34 cmake-3.24.3/
drwxrwxrwx  29 macports  admin  928 Nov  1 10:55 cmake-v3.24.3-c974557598645360fbabac71352b083117e3cc17/
$ ll cmake*
cmake-3.24.3:

cmake-v3.24.3-c974557598645360fbabac71352b083117e3cc17:
total 440
-rw-rw-rw-    1 macports  admin   1411 Nov  1 10:55 .clang-format
-rw-rw-rw-    1 macports  admin   1377 Nov  1 10:55 .clang-tidy
drwxrwxrwx    7 macports  admin    224 Nov  1 10:55 Auxiliary/
-rw-rw-rw-    1 macports  admin  10073 Nov  1 10:55 CMakeCPack.cmake
-rw-rw-rw-    1 macports  admin  12255 Nov  1 10:55 CMakeCPackOptions.cmake.in
-rw-rw-rw-    1 macports  admin    153 Nov  1 10:55 CMakeGraphVizOptions.cmake
-rw-rw-rw-    1 macports  admin  34829 Nov  1 10:55 CMakeLists.txt
-rw-rw-rw-    1 macports  admin   4481 Nov  1 10:55 CMakeLogo.gif
-rw-rw-rw-    1 macports  admin   3118 Nov  1 10:55 CONTRIBUTING.rst
-rw-rw-rw-    1 macports  admin    566 Nov  1 10:55 CTestConfig.cmake
-rw-rw-rw-    1 macports  admin   6915 Nov  1 10:55 CTestCustom.cmake.in
-rw-rw-rw-    1 macports  admin   4802 Nov  1 10:55 CompileFlags.cmake
-rw-rw-rw-    1 macports  admin   5440 Nov  1 10:55 Copyright.txt
-rw-rw-rw-    1 macports  admin    374 Nov  1 10:55 DartConfig.cmake
drwxrwxrwx   22 macports  admin    704 Nov  1 10:55 Help/
drwxrwxrwx    5 macports  admin    160 Nov  1 10:55 Licenses/
drwxrwxrwx  441 macports  admin  14112 Nov  1 10:55 Modules/
drwxrwxrwx    5 macports  admin    160 Nov  1 10:55 Packaging/
-rw-rw-rw-    1 macports  admin   3951 Nov  1 10:55 README.rst
drwxrwxrwx  765 macports  admin  24480 Nov  1 10:55 Source/
drwxrwxrwx   13 macports  admin    416 Nov  1 10:55 Templates/
drwxrwxrwx  307 macports  admin   9824 Nov  1 10:55 Tests/
drwxrwxrwx   29 macports  admin    928 Nov  1 10:55 Utilities/
-rwxrwxrwx    1 macports  admin  64762 Nov  1 10:55 bootstrap*
-rw-rw-rw-    1 macports  admin    789 Nov  1 10:55 cmake_uninstall.cmake.in
-rwxrwxrwx    1 macports  admin     99 Nov  1 10:55 configure*
-rw-rw-rw-    1 macports  admin  28046 Nov  1 10:55 doxygen.config

WORKSRCDIR is set to the short version, which is empty ... here's a prior one that's working:

$ pwd
/opt/local/var/macports/build/_opt_sources_MacPorts_ports_github_macports_devel_cmake/cmake/work
$ ll
total 8
drwxrwxrwx   2 macports  admin   64 Dec  7 14:11 .home/
-rw-rw-rw-   1 macports  admin  219 Dec  7 14:11 .macports.cmake.state
drwxrwxrwx   2 macports  admin   64 Dec  7 14:11 .tmp/
lrwxrwxrwx   1 macports  admin   54 Dec  7 14:11 cmake-3.24.3@ -> cmake-v3.24.3-c974557598645360fbabac71352b083117e3cc17
drwxrwxrwx  31 macports  admin  992 Dec  7 14:11 cmake-v3.24.3-c974557598645360fbabac71352b083117e3cc17/

So looks like the prior symlink was replaced by a directory ... oops!

[michaelld (Michael Dickens)]

oh wow ... the commit being reverted (7921b2e05) is from December 29, 2017 at 10:54:09 AM EST ... can't say I'm happy about that reversion given that it will break ports like cmake. The commit message for the reversion says This change silently broke an unknown number of ports due to different behaviour of symlinks vs directories. See e.g. slime, scm_breeze. The reversion may also break things, but at least they'll give an error rather than silently installing nothing but a broken link. So ... the original commit broke stuff, and reverting it also breaks stuff ... which is worse? hmmm ...

[michaelld (Michael Dickens)]

Luckily this not part of the current MP release, so there's time to fix it before the next release :)

[jmroot (Joshua Root)]

For most ports, setting worksrcdir correctly is all that's needed to avoid problems. If there are ports where it's difficult to work out the value of worksrcdir a priori, I'd be open to having an option that can be set to enable the behaviour (though I think renaming rather than symlinking would still be safer in that case.)

[jmroot (Joshua Root)]

In 8ae0d73589330693f3b17849fdd5e65f0f56a5c1/macports-base (master):

Add extract.rename option

This restores the functionality of 7921b2e on an opt-in basis and
without the semantic differences introduced by creating a symlink.

See: #66415

[michaelld (Michael Dickens)]

This works for cmake, but not cmake-devel ... Replying to jmroot:

In 8ae0d73589330693f3b17849fdd5e65f0f56a5c1/macports-base (master):

$ sudo port -d patch cmake-devel
[snip]
DEBUG: system:  cd "/opt/local/var/macports/build/_opt_sources_MacPorts_ports_github_macports_devel_cmake-devel/cmake-devel/work" && /opt/local/bin/lbzip2 -dc '/opt/sources/MacPorts/distfiles/cmake/cmake-5676593be9bd3a26995f35b9db8fe5b9af8ea32e.tar.bz2' | /usr/bin/tar -xf -
DEBUG: euid/egid changed to: 0/0
DEBUG: chowned /opt/local/var/macports/build/_opt_sources_MacPorts_ports_github_macports_devel_cmake-devel/cmake-devel/work to macports
DEBUG: euid/egid changed to: 503/501
DEBUG: extract.rename: Renaming cmake-5676593be9bd3a26995f35b9db8fe5b9af8ea32e -> cmake-5676593be9bd3a26995f35b9db8fe5b9af8ea32e
Error: Failed to extract cmake-devel: error renaming "/opt/local/var/macports/build/_opt_sources_MacPorts_ports_github_macports_devel_cmake-devel/cmake-devel/work/cmake-5676593be9bd3a26995f35b9db8fe5b9af8ea32e" to "/opt/local/var/macports/build/_opt_sources_MacPorts_ports_github_macports_devel_cmake-devel/cmake-devel/work/cmake-5676593be9bd3a26995f35b9db8fe5b9af8ea32e/cmake-5676593be9bd3a26995f35b9db8fe5b9af8ea32e": trying to rename a volume or move a directory into itself
DEBUG: Error code: NONE
[snip]

$ pushd $(port work cmake-devel)
/opt/local/var/macports/build/_opt_sources_MacPorts_ports_github_macports_devel_cmake-devel/cmake-devel/work /opt/sources/MacPorts/ports/github_macports

$ ll
total 8
drwxrwxrwx   2 macports  wheel   64 Dec 12 15:07 .home/
-rw-rw-rw-   1 macports  wheel  143 Dec 12 15:07 .macports.cmake-devel.state
drwxrwxrwx   2 macports  wheel   64 Dec 12 15:07 .tmp/
drwxrwxrwx  29 macports  wheel  928 Nov 30 08:57 cmake-5676593be9bd3a26995f35b9db8fe5b9af8ea32e/

[michaelld (Michael Dickens)]

The ll above is what I see when using port still using the old linking method ... meaning, it doesn't actually do anything for this style of worksrcdir ... hopefully this helps fix the issue!

[jmroot (Joshua Root)]

This is probably something that should be handled in the gitlab portgroup.

[jmroot (Joshua Root)]

For that matter, why is cmake (not -devel) using gitlab generated downloads at all? There are proper release tarballs on GitHub and that's where ​https://cmake.org/download/ is pointing now.

[michaelld (Michael Dickens)]

Interesting & good point! Well, Kitware has their own gitlab instance running at https://gitlab.kitware.com/ ... that's what those Portfiles are using. Looking at the downloads, I see that they go direct to Github ... I'll look into changing them over to that download method instead. good catch!

[jmroot (Joshua Root)]

In b49168b9a911c904f55f7e721e1b0239a39f831e/macports-base (master):

extract.rename improvements

Rename to $distname instead of $worksrcdir as the latter may be set to
a subdir. Don't try and fail to rename if the dir name is already
correct.

See: #66415

[jmroot (Joshua Root)]

In 596e827d90276321a98011b594c8b6f856394b27/macports-ports (master):

gitlab pg: set extract.rename if available

See: #66415

[michaelld (Michael Dickens)]

Closing this since it has been fixed well enough, even if still a bit of a work in progress