Re: cmake 3.1
On Wednesday January 14 2015 12:43:27 Mojca Miklavec wrote: You could already use a maintainer timeout by now. ? But I had some (very weird) issues with the update (see the ticket) and I would suggest performing at least some very basic tests after that fundamental change in Modules/Platform/Darwin.cmake. One would hope that the cmake devs tested that new version, no? I wrote the details in the ticket. https://trac.macports.org/ticket/46493 Re: extraction: I've been having more and more crashes using port:gnutar to access or create compressed tarchives, while the system tar command (that doesn't even need to be told to decompress before accessing an archive) does not have such issues. Any chance that's related? R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: cmake 3.1
On Wed, Jan 14, 2015 at 3:34 PM, René J.V. wrote: On Wednesday January 14 2015 12:43:27 Mojca Miklavec wrote: You could already use a maintainer timeout by now. ? But I had some (very weird) issues with the update (see the ticket) and I would suggest performing at least some very basic tests after that fundamental change in Modules/Platform/Darwin.cmake. One would hope that the cmake devs tested that new version, no? Yes, I would expect them to test the new version, but I wouldn't expect them to test it on utterly weird setups such as the ones where we have been bitten by the problem: - Mac OS X 10.6 - with libc++ (or another library) installed under /usr, but not under /path/to/MacOSX10.6.sdk/usr - trying to compile software with clang-3.4 against libc++ (This is not the only setup where CMake misbehaved, but it was difficult to see problems under normal circumstances.) Re: extraction: I've been having more and more crashes using port:gnutar to access or create compressed tarchives, while the system tar command (that doesn't even need to be told to decompress before accessing an archive) does not have such issues. Any chance that's related? Probably. But unrelated: am I the only one who gets different checksums than the ones cited in the ticket? The ticket was created a few days ago and the file on their server is one month old, so it's not like they made a silent change in the last few days. Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: cmake 3.1
On Thu, Jan 8, 2015 at 10:27 PM, Marius Schamschula wrote: On Jan 8, 2015, at 3:22 PM, René J.V. Bertin wrote: On Thursday January 08 2015 14:46:57 Marius Schamschula wrote: Rene, I posted a ticket with an updated Portfile: see https://trac.macports.org/ticket/46493 Great, any issues using that new version? I haven’t tested it, but in the past cmake has caused more errors when building then when using the resulting executable. The only change with the new version is that patch-Modules-Platform-Darwin.cmake.diff no longer works, as Darwin.cmake appears to have been fundamentally rewritten. As cmake is not openmaintainer, we will have to wait for the maintainer to take action. You could already use a maintainer timeout by now. But I had some (very weird) issues with the update (see the ticket) and I would suggest performing at least some very basic tests after that fundamental change in Modules/Platform/Darwin.cmake. I wrote the details in the ticket. Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
