Update: cmake 3.1.0

[Schamschula (Marius Schamschula)]

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

[mkae (Marko Käning)]

deleting the maintainer wasn't indented above! :)

[michaelld (Michael Dickens)]

Cc Me!

[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.

[mojca (Mojca Miklavec)]

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.)

[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.

[mojca (Mojca Miklavec)]

Another patch for cmake upgrade to 3.1.0 that also fixes patches

[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.

[Schamschula (Marius Schamschula)]

In the meantime cmake has been updated to version 3.1.1.

[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?

[Schamschula (Marius Schamschula)]

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

[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.

[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.

[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.

[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 ;)

[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!

[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 =)

[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.

[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.

[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 :)

[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.

[Schamschula (Marius Schamschula)]

One more update… cmake 3.1.3

[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".)

[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.

[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.

[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 ;)

[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).

[larryv (Lawrence Velázquez)]

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

[mojca (Mojca Miklavec)]

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

• ​http://www.cmake.org/files/v3.2/?C=M;O=D

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.

[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.

[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.

[michaelld (Michael Dickens)]

Committed in r133041.