Opened 10 years ago

Closed 10 years ago

#46493 closed update (fixed)

Update: cmake 3.1.0

Reported by: Schamschula (Marius Schamschula) Owned by: cssdev
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: michaelld (Michael Dickens), jeremyhu (Jeremy Huddleston Sequoia), mojca (Mojca Miklavec)
Port: cmake

Description

cmake has been updated to version 3.1.0. See http://www.kitware.com/blog/home/post/812 for details.

Attachments (7)

cmake-3.1.0.diff (5.1 KB) - added by mojca (Mojca Miklavec) 10 years ago.
Another patch for cmake upgrade to 3.1.0 that also fixes patches
Portfile-cmake.diff (1.2 KB) - added by Schamschula (Marius Schamschula) 10 years ago.
Portfile-cmake-3.1.0-3.1.2.diff (875 bytes) - added by Schamschula (Marius Schamschula) 10 years ago.
cmake_3.1.2.diff (7.5 KB) - added by michaelld (Michael Dickens) 10 years ago.
cmake-3.1.2-RJVB.diff (18.6 KB) - added by RJVB (René Bertin) 10 years ago.
Portfile-cmake-3.1.2-3.1.3.diff (875 bytes) - added by Schamschula (Marius Schamschula) 10 years ago.
cmake_3.1.3.diff (10.1 KB) - added by michaelld (Michael Dickens) 10 years ago.

Download all attachments as: .zip

Change History (39)

comment:1 Changed 10 years ago by mkae (Marko Käning)

Cc: css@… removed
Version: 2.3.3

comment:2 Changed 10 years ago by mkae (Marko Käning)

Cc: css@… added

deleting the maintainer wasn't indented above! :)

Last edited 10 years ago by mkae (Marko Käning) (previous) (diff)

comment:3 Changed 10 years ago by michaelld (Michael Dickens)

Cc: michaelld@… added

Cc Me!

comment:4 Changed 10 years ago by michaelld (Michael Dickens)

Cc: css@… removed
Owner: changed from macports-tickets@… to css@…

comment:5 Changed 10 years ago by mojca (Mojca Miklavec)

There is something weird about this. First of all, I get different checksums for http://www.cmake.org/files/v3.1/cmake-3.1.0.tar.gz:

checksums           rmd160  082f6fba389cc3eeb75a004eae7c17e2202bba4e \
                    sha256  0aa60bfa4d396180759690b700c79a4869dc23735646579ee23102bac0a85658

Second, extract fails on 10.7:

DEBUG: Assembled command: 'cd "/path/to/cmake/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/cmake/cmake-3.1.0.tar.gz' | /usr/bin/gnutar --no-same-owner -xf -'
DEBUG: Executing command line:  cd "/path/to/cmake/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/cmake/cmake-3.1.0.tar.gz' | /usr/bin/gnutar --no-same-owner -xf - 

gzip: /opt/local/var/macports/distfiles/cmake/cmake-3.1.0.tar.gz: not in gzip format

but I can manually extract the file without problems:

$ tar xvzf cmake-3.1.0.tar.gz 
x cmake-3.1.0/.gitattributes
x cmake-3.1.0/.hooks-config.bash
x cmake-3.1.0/Auxiliary/bash-completion/cmake
...

With a lower priority one also has to fix the "broken" livecheck which only checks whether there exists any new version of CMake 1.0.x, but doesn't check for any newer branch.

Last edited 10 years ago by mojca (Mojca Miklavec) (previous) (diff)

comment:6 Changed 10 years ago by mojca (Mojca Miklavec)

Cc: jeremyhu@… mojca@… added

I also believe that removal of patch-Modules-Platform-Darwin.cmake.diff calls for some additional testing. In particular we need to test whether libc++ still works properly on 10.6 and whether one can still prevent auto-appending of the SDK. I see that the code handling SDK settings has been completely revamped.

(A while ago we had problems with root6 on 10.6.)

comment:7 Changed 10 years ago by mojca (Mojca Miklavec)

See #44125 and http://www.cmake.org/Bug/view.php?id=15040 to get the idea of what we might want to test.

Changed 10 years ago by mojca (Mojca Miklavec)

Attachment: cmake-3.1.0.diff added

Another patch for cmake upgrade to 3.1.0 that also fixes patches

comment:8 Changed 10 years ago by mojca (Mojca Miklavec)

I at least somewhat understand my problems with tar and gzip, but didn't fix the problem yet. I sent an email to the mailing list.

But now that I got the proper file, I'm attaching a revised patch that also fixes minor issues with the patches:

--->  Applying patch-Modules-FindFreetype.cmake.diff
patching file Modules/FindFreetype.cmake
Hunk #1 succeeded at 57 (offset 2 lines).
Hunk #2 succeeded at 74 (offset 6 lines).
Hunk #3 succeeded at 91 with fuzz 2 (offset 11 lines).
--->  Applying patch-Modules-FindQt4.cmake.diff
patching file Modules/FindQt4.cmake
Hunk #1 succeeded at 741 (offset 13 lines).

In addition to that the removed patch needs to be deleted. I didn't do extensive testing yet.

Last edited 10 years ago by mojca (Mojca Miklavec) (previous) (diff)

comment:9 Changed 10 years ago by Schamschula (Marius Schamschula)

In the meantime cmake has been updated to version 3.1.1.

Changed 10 years ago by Schamschula (Marius Schamschula)

Attachment: Portfile-cmake.diff added

comment:10 Changed 10 years ago by RJVB (René Bertin)

Does this cmake version have a more robust Xcode generator that generates valid .xcodeprojs even for (large) projects that weren't meant to be used with that generator from the start?

Changed 10 years ago by Schamschula (Marius Schamschula)

comment:11 Changed 10 years ago by Schamschula (Marius Schamschula)

Another update to cmake 3.1.2. Patch file is to be applied after fitst applying cmake-3.1.0.diff.

Changed 10 years ago by michaelld (Michael Dickens)

Attachment: cmake_3.1.2.diff added

comment:12 Changed 10 years ago by michaelld (Michael Dickens)

I just attached a unified patch bumping cmake to version 3.1.2, which should replicate the behavior of all current CMake patches including "patch-Modules-Platform-Darwin.cmake.diff". It passes "make test" excepting Tcl, which is an issue with how CMake parses frameworks versus libraries; it's the same issue as with CMake 3.0.2, and should not impact projects using cmake. This version works for me on my projects; can others please test and verify both building and usage? I'm adding myself as a co-maintainer; I'll verify with CSS to make sure this is OK.

comment:13 Changed 10 years ago by jmroot (Joshua Root)

Patch changes look right to me. Those patches include the fix for #44581, so if you want to verify that still works, temporarily move aside the SDK for your current OS X version and try building cmake. Those changes should go upstream BTW, I’m pretty sure they reflect what Apple’s tools accept as valid SDK/MDT combinations much better than upstream cmake’s current checks.

comment:14 Changed 10 years ago by michaelld (Michael Dickens)

Without this patch, after temporarily moving my OS's SDK out of the way, configuring cmake fails. So, yes, these 2 patches do seem to do the trick. I'll send an email upstream with the patch and info. I don't know the devs personally, but it's worth a try.

comment:15 Changed 10 years ago by RJVB (René Bertin)

Can someone please upload a tarball of the complete port directory, or give a summary of which attached (here or elsewhere!) patches to apply against what baseline? I admit I'm a bit lost here, and would like to spend more time trying out the resulting build than figuring out how to get the appropriate build in the 1st place ;)

comment:16 Changed 10 years ago by michaelld (Michael Dickens)

Your friends here are "svn status" followed by "svn revert". If you do:

cd `port dir cmake`
svn status

this will list the files that have been modified (M), added (A), or are not recognized (?) by svn as part of the repo.

For those files modified or added (e.g., "Portfile"), you would do:

svn revert Portfile

to revert it to the latest repo version; repeat for all such files (but, hopefully obviously, changing the name to the actual filename, not repeating "Portfile" for each file).

Once "svn status" comes back with just "?"s, or nothing at all, then apply the last patch attached here (currently "cmake_3.1.2.diff​"). Let's assume you download the patch as "~/Downloads/cmake_3.1.2.diff"; then you would do:

patch -p0 < ~/Downloads/cmake_3.1.2.diff

but, hopefully obviously, use the actual patch file path and name.

HTH!

comment:17 Changed 10 years ago by RJVB (René Bertin)

Yeah. I don't really get the reason behind the svn revert, but if my port dir is "stock" that call shouldn't do anything anyway.

I'll give a yell if I get stuck =)

comment:18 Changed 10 years ago by michaelld (Michael Dickens)

If your port's dir is stock with the repo, then "svn revert" should do nothing since there's nothing to revert. git has this feature as well: "git checkout -- [filename]" reverts the file back to the last checkin's version. It's really quite useful sometimes.

comment:19 Changed 10 years ago by RJVB (René Bertin)

Yeah, it sure beats git reset --hard ... if I can remember the selective command ;)

Anyway, no one apparently updated the +gui patch yet. I think I've managed; it so I'll attach it to this ticket.

comment:20 Changed 10 years ago by RJVB (René Bertin)

BTW, it'd be nice if during testing some of you could also check the Xcode generator. For me it's proven to be useless in the sense that whenever for a more complex project I'd have loved to have a proper Xcode project, cmake generated corrupt projects. I reported that upstream, but was told 1) to try with the latest version (logical) and 2) to come up with a simpler testcase than a KDE application (can't remember which one reported). That latter point is a bit ... challenging :)

Changed 10 years ago by RJVB (René Bertin)

Attachment: cmake-3.1.2-RJVB.diff added

comment:21 Changed 10 years ago by RJVB (René Bertin)

Here's my version. I've checked and updated the patch for building +gui . It'll build against Qt5 by default if that version is available, so I added a +qt4 variant for those who'd like to build against Qt4 despite having Qt5. Both versions build without errors and appear to work.

Initial testing on a project I am working on revealed no issues, nor a huge project like Calligra (checked only by comparing the respective CMakeCache.txt files, not by spending 2x 4hours building :)). Maybe slightly faster operation, though.

Changed 10 years ago by Schamschula (Marius Schamschula)

comment:22 Changed 10 years ago by Schamschula (Marius Schamschula)

One more update… cmake 3.1.3

Last edited 10 years ago by Schamschula (Marius Schamschula) (previous) (diff)

comment:23 Changed 10 years ago by mojca (Mojca Miklavec)

René: I didn't test the Qt4 vs Qt5 yet, but it's nice that you figured it out. However the patch seems a bit suboptimal. I'm copy-pasting it here:

variant gui description {Qt based cmake-gui} {
    if {[variant_isset qt4]} {
        # qt4 being requested we have to make sure CMake doesn't detect and use
        # qt5 if that happens to be installed too:
        patchfiles-append   patch-CMakeLists.txt.diff \
                            patch-CMakeLists-4qt4.diff
    } else {
        # this is how cmake checks what Qt version to use:
        if {[file exists ${prefix}/lib/pkgconfig/Qt5Widgets.pc]} {
            PortGroup qt5 1.0
        } else {
            PortGroup qt4 1.0
        }
        patchfiles-append   patch-CMakeLists.txt.diff
    }
}

The problem is that user trying to install cmake +gui would still end up linking against qt4, but the variant qt4 won't be enabled.

How about using qt4 and qt5 as option names (either keeping or dropping gui; if kept, +gui would automatically enable one of the two qt options; on the other hand the option gui wouldn't really make any difference, so it could just as well be dropped)? I would suggest to try to decide what variants should be used and then improve the patch a bit to make it work "consistently".

Michael, thanks a lot for stepping forward. CMake is one of the essential ports for many packages, so it would be great to have someone who can help him keep the port up to date. (I would have volunteered earlier if the port was unmaintained, but the maintainer showed up every now and then.)

Did Chris ever respond? It's also true that he didn't object the addition of a new maintainer, but I'm curious if he explicitly agreed. (Most commits in the last two years were done as "maintainer timeout".)

comment:24 Changed 10 years ago by michaelld (Michael Dickens)

@mojca: I've heard nothing from Chris in a while. I'll go ahead and -assume- this is OK. I use CMake extensively, so I have a real interest in it working well. I've never used the GUI, but I'm game.

Can we agree to move the +gui issue to another ticket? I'd like to get cmake bumped to 3.1.3 & then we can handle +gui separately.

comment:25 Changed 10 years ago by mojca (Mojca Miklavec)

Please do. I would also prefer to see the version bumped.

The slightly suboptimal detection of Qt apparently didn't affect anyone but René so far and it might require some discussion (= time) and it is completely orthogonal to version upgrade.

I would like to suggest you to change the order of maintainers (that is: put your name first), so that the tickets related to cmake will be assigned to you.

Changed 10 years ago by michaelld (Michael Dickens)

Attachment: cmake_3.1.3.diff added

comment:26 Changed 10 years ago by michaelld (Michael Dickens)

OK; here's the latest patchset:

1) bump cmake to 3.1.3; 2) fix patches for 3.1.3; 3) tweak patches to just list files (*.orig and *, respectively), no dates (as comes with "diff -u"); 4) add me as co-maintainer with css, me listed first.

Any objections to this being committed over the coming weekend? Speak soon, or hold your peace ;)

comment:27 Changed 10 years ago by michaelld (Michael Dickens)

For the other cmake issues: +gui and bundle (or whatever it is that René has found), please open a new ticket for each. I think they should be fixed, but this ticket is about updating cmake to a newer version (and the related patch changes to do so).

comment:28 in reply to:  26 Changed 10 years ago by larryv (Lawrence Velázquez)

A nudge rather than an objection: If you could handle #46739 also, that would be great.

comment:29 Changed 10 years ago by mojca (Mojca Miklavec)

If you don't hurry up, we'll have to rename the ticket into "update to 3.2.0" ;)

That version might introduce some "problems" though:

Deprecated and Removed Features:

* Files written in the "cmake-language(7)", such as "CMakeLists.txt"
  or "*.cmake" files, are now expected to be encoded as UTF-8.  If
  files are already ASCII, they will be compatible.  If files were in
  a different encoding, including Latin 1, they will need to be
  converted.

comment:30 Changed 10 years ago by michaelld (Michael Dickens)

Yes, I see what you mean Mojca; I watch their github commits.

Hmmm ... Most of the *CMake* files I know of are ASCII. I don't think I've ever encountered on that's UTF-8 or Latin 1 or anything else. I'll certainly do some testing on the ports that I use & see how they go.

comment:31 Changed 10 years ago by mojca (Mojca Miklavec)

I'm not expecting lots of problems, but I wouldn't be surprised if some problems appear every now and then. I've seen many C++ files in weird encodings for example. Why would people avoid non-ASCII in CMake files (in comments, listing names of authors for example)? Anyway, I didn't want to say that this will be a problem, I just pointed out where it could go wrong.

My remark about 3.2 was just some kind of a parody because this ticket was opened three releases back.

comment:32 Changed 10 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: newclosed

Committed in r133041.

Note: See TracTickets for help on using tickets.