submission of the Charm time tracker for Qt4 or Qt5

[RJVB (René Bertin)]

This is a port of the Charm time tracker, adapted to MacPorts.

[mf2k (Frank Schima)]

Please just attach the Portfile.

[ryandesign (Ryan Carsten Schmidt)]

Thanks. Some observations:

• Why call github.setup with a commit hash? Why not use the 1.8.0 tag? Livecheck would work better and you wouldn't have to define version separately.
• Why is fetch.type git necessary?
• The caterory should be changed because we do not have a category "qt".
• The homepage line should be removed because the github portgroup sets it for you.
• Since the cmake portgroup seems to always be required, I'd recommend including it at the top of the portfile right above the github portgroup and removing it from the two subport blocks where you currently have it.
• Remove the quotation marks around the value of the conflicts option; they're not needed.
• In the post-destroot block, remove the directory creation, because MacPorts automatically creates standard directories for you.
• Use ${version} in your configure.args-append statements instead of hardcoding the version number there again.

[mkae (Marko Käning)]

Cc Me!

[RJVB (René Bertin)]

Replying to ryandesign@…:

• Why call github.setup with a commit hash? Why not use the 1.8.0 tag?

I'm not really familiar with git tags, and I *guess* that using a commit tag gives a potentially new snapshot of a given version.

Livecheck would work better and you wouldn't have to define version separately.

Livecheck with git?

• Why is fetch.type git necessary?

I suppose it's redundant, then?

• The caterory should be changed because we do not have a category "qt".

Do you have a better suggestion?

• Remove the quotation marks around the value of the conflicts option; they're not needed.

A bit confusing to know when they're needed or not!

[mkae (Marko Käning)]

Replying to rjvbertin@…:

Livecheck with git?

Ryan means that livecheck would be better if you use a tagged version, as your latest update does. :)

• The caterory should be changed because we do not have a category "qt".

Do you have a better suggestion?

I suggest "office".

I tried to build this on Snow Leopard here and I get:

$ port info
Can't map the URL 'file://.' to a port description file ("can't read "qt_apps_dir": no such variable").
Please verify that the directory and portfile syntax are correct.
To use the current port, you must be in a port's directory.

I think the Portfile needs some restructuring.

[mkae (Marko Käning)]

corrected Portfile

[mkae (Marko Käning)]

BTW, please consider this:

$ port lint --nitpick
--->  Verifying Portfile for charm
Warning: Patchfile patch-CMakeFiles.patch does not follow the source patch naming policy "patch-*.diff"
Warning: Patchfile adapt-to-osx-macports.patch does not follow the source patch naming policy "patch-*.diff"
--->  0 errors and 2 warnings found.

[mkae (Marko Käning)]

My Portfile suggestion is still uncommitted, because we need to come to a decision regarding "qt5-charm", which I think should be "charm-qt5" rather.

But I agree with Mojca that a variant "charm +qt5" is the better way to go, perhaps!

Anyway, I just tested the app. It works. :)

[RJVB (René Bertin)]

Replying to mk@…:

BTW, please consider this:

For the future ... but what's the point in adding extra noise by prepending "patch-" to all .diff files?

you use a tagged version, as your latest update does. :)

If I understand correctly, livecheck has an option to detect new commits? How? I'm not sure I see the importance of that, unless it also shows the commit messages so one can assess if there's reason to update the port?

Where do the checksums come from, and why did you remove "/monthly" from the long description?

Also, any better suggestions for the Qt5 subport name? "q5-Charm" to be more in line with the perl ports? Charm-qt5? Or should I inverse the whole logic because the original build system will prefer Qt5 over Qt4 (without any added functionality that I can see)? Or ... simply respect that choice (maybe with a variant to force the use of Qt4 because that's my own preference, and a variant is probably easier to drop, at least conceptually)?

I agree that, contrary to QtCurve, Charm could put the Qt version selection in a variant, because ultimately there's little use to having both versions installed. And when I say ultimately here, it's exactly that: I think we're in a period where at least for certain applications it *could* be of interest (to certain users) to have both versions installed.

[RJVB (René Bertin)]

BTW, curious that the reference to qt_apps_dir was accepted for me, before a Qt port group was included. Is that because tclsh somehow has a different order of execution on 10.9 than on 10.6, or is the information from port group files cached by portindex? I most likely didn't rerun portindex after moving the incriminated configure.args-append line above the subport blocks.

[mkae (Marko Käning)]

Replying to rjvbertin@…:

For the future ... but what's the point in adding extra noise by prepending "patch-" to all .diff files?

I don't need it. This is what "port lint" complains about. :) As the list!

If I understand correctly, livecheck has an option to detect new commits? How?

No. If you use a version tag it is able to figure out whether there's a new version.

(I haven't looked into that yet, still needs to be done.)

Where do the checksums come from,

The port command computes them. You can see them in the log, or when you issue sudo port -d extract!

and why did you remove "/monthly" from the long description?

I didn't remove anything, I added "/monthly", because I wondered why the text only contained "weekly".

I agree that, contrary to QtCurve, Charm could put the Qt version selection in a variant,

Yes.

And when I say ultimately here, it's exactly that: I think we're in a period where at least for certain applications it *could* be of interest (to certain users) to have both versions installed.

I see that point.

This needs further discussion on the list, I think.

[mkae (Marko Käning)]

Replying to rjvbertin@…:

BTW, curious that the reference to qt_apps_dir was accepted for me

THAT WAS IRRITATING ME big time as well and I believe that this must be posted on the list, to make the MacPorts core devs aware of it!!!

I was flabbergasted when I tried to install this port with your initial Portfile, as it was failing all around me and I wondered how you were able to get it to work on your system.

[mkae (Marko Käning)]

I forgot to mention that I have installed and tested only the Qt4 version of this port.

[mkae (Marko Käning)]

Now with github properly pulling from releases

[mkae (Marko Käning)]

$ port livecheck charm
charm seems to have been updated (port version: 1.8.0, new version: 1.8.0rc1)

:-)

Well, but that version isn't in GitHub's releases yet.

[RJVB (René Bertin)]

Replying to mk@…:

I forgot to mention that I have installed and tested only the Qt4 version of this port.

Note that I patched nothing that's Qt5 specific, so the exact same code gets compiled against that version. In fact, part of my patches include certain code that only got activated under Qt5 (#ifdef Q_OS_OSX) for Qt4 too (which only defines Q_OS_MAC).

Marko, have you checked that the 1.8.0 tag includes the commit my original submission references? IIRC, that commit (or one just before) corrects an issue on OS X. Also, I'm not convinced that the livecheck system correctly interprets 1.8.0rc1 (release candidate 1) as coming *before* 1.8.0!!

[mkae (Marko Käning)]

Replying to rjvbertin@…:

Marko, have you checked that the 1.8.0 tag includes the commit my original submission references? IIRC, that commit (or one just before) corrects an issue on OS X.

Oh, correct! I didn't re-test the patch phase with version 1.8.0! This fails already for the 1st patch file

:debug:patch Executing command line:  cd "/opt/local/var/macports/build/_Users_marko_WC_SVN_MacPorts_office_charm/charm
/work/Charm-1.8.0" && /usr/bin/patch -p0 < '/Users/marko/WC/SVN/MacPorts/office/charm/files/patch-CMakeFiles.patch'
:info:patch patching file CMakeLists.txt
:info:patch Hunk #2 FAILED at 63.
:info:patch Hunk #3 succeeded at 107 with fuzz 2 (offset -19 lines).
:info:patch Hunk #4 succeeded at 180 (offset -19 lines).
:info:patch Hunk #5 succeeded at 208 (offset -19 lines).
:info:patch Hunk #6 succeeded at 237 (offset -19 lines).
:info:patch 1 out of 6 hunks FAILED -- saving rejects to file CMakeLists.txt.rej
:info:patch patching file Charm/CMakeLists.txt
:info:patch Hunk #1 succeeded at 172 (offset -8 lines).
:info:patch Hunk #2 succeeded at 208 (offset -9 lines).
:info:patch Command failed:  cd "/opt/local/var/macports/build/_Users_marko_WC_SVN_MacPorts_office_charm/charm/work/Charm-1.8.0" && /usr/bin/patch -p0 < '/Users/marko/WC/SVN/MacPorts/office/charm/files/patch-CMakeFiles.patch'
:info:patch Exit code: 1

Could you change your patches according to the 1.8.0 release, please?

Also, I'm not convinced that the livecheck system correctly interprets 1.8.0rc1 (release candidate 1) as coming *before* 1.8.0!!

Yes, you're right, of course.

[RJVB (René Bertin)]

Replying to mk@…:

Replying to rjvbertin@…:

Marko, have you checked that the 1.8.0 tag includes the commit my original submission references? IIRC, that commit (or one just before) corrects an issue on OS X.

Oh, correct! I didn't re-test the patch phase with version 1.8.0!

[...]

Could you change your patches according to the 1.8.0 release, please?

Erm, no. You didn't check how recent v1.8.0 is. If I'm not mistaken, it corresponds to commit 66f03ca1137cc7bfe7489c86f9724825bc1b905c, which dates back to

June 26th

*2013*

So, no. Lots of things have been modified since that I for one don't want to dunk just in favour of being squat on a version release.

[mkae (Marko Käning)]

Oh, I see, that project calls for an update. Wasn't aware of that.

So, I think one should go back to use your git hash.

Sorry for the noise.

[mkae (Marko Käning)]

I just tried the latest git hash (aca5faf6) and MacPorts gives me this on install:

Warning: violation by /opt/local/Charm.app
Warning: charm violates the layout of the ports-filesystems!
Warning: Please fix or indicate this misbehavior (if it is intended), it will be an error in future releases!

Wondering why you based your patches on ad76bf18.

[mkae (Marko Käning)]

functional Portfile (using git version ad76bf18, i.e. not the most up-to-date one)

[mkae (Marko Käning)]

Ooops, now it works also with the latest git version (I had forgotten to include your 1st patch)

[mkae (Marko Käning)]

Another little update (qt5 not yet tested though)

[ryandesign (Ryan Carsten Schmidt)]

Replying to rjvbertin@…:

Replying to ryandesign@…:

• Why call github.setup with a commit hash? Why not use the 1.8.0 tag?

I'm not really familiar with git tags, and I *guess* that using a commit tag gives a potentially new snapshot of a given version.

Developers of most software projects commit changes to their software to their revision control system in logical chunks, called commits or revisions, and when they have finished a set of work they invent a new version number for the project, "tag" that version with a new version number, and release it to the world. Typically in MacPorts we want to follow a project's releases, not its commits, because commits typically represent an intermediate stage of development that may not be suitable for public consumption. On the other hand, sometimes the latest release has bugs that were fixed right after release, and in those cases we may use a newer commit, or add local patchfiles to deal with the issue. Sometimes developers release software very infrequently, and we may follow commits in that case, if we cannot convince the developers to adopt a more frequent release schedule.

Livecheck would work better and you wouldn't have to define version separately.

Livecheck with git?

Since we usually follow releases, not commits, usually we want livecheck to tell us about releases, not commits. That's what happens when you invoke github.setup with a tag (i.e. release) name. If, on the other hand, you invoke github.setup with a commit hash, then livecheck changes to tell you about newer commits.

• Why is fetch.type git necessary?

I suppose it's redundant, then?

Not at all. Perhaps you're confused about the difference between git and github. git is a client and server software program for managing a revision control system. github is a service that provides hosting for git repositories, issue trackers, wikis, web sites, code fragments, and so forth. In addition, github can generate tarballs for any revision or tag of any hosted git repository. The github portgroup sets up defaults appropriate for interacting with projects hosted at github, including using those tarballs. In MacPorts, we prefer ports to fetch their code from tarballs, zip files, or similar distfiles that are downloaded from a web or ftp server. This is preferred because the portfile lists checksums for each such file, so when the file arrives, you know it is identical to the one the port author used and tested. Furthermore, the MacPorts infrastructure automatically mirrors distfiles on a global network of servers, resulting in fault tolerance and faster downloads. Finally, distfiles are cached on the local system, so if you retry a build, you don't need to download the distfile each time. If you use fetch.type git, you indicate that you want to forgo all those advantages and communicate directly with the underlying git repository every time you build a port. There are some situations where that is needed, some examples of which are given in the comments in the github portgroup, but when it is not needed, it should be avoided.

• Remove the quotation marks around the value of the conflicts option; they're not needed.

A bit confusing to know when they're needed or not!

The most common reason to need quotes is if you are including whitespace in the variable's value, although even then it's only needed when dealing with pure variables (i.e. those you set with the Tcl command set), not MacPorts "options", which are a more advanced kind of variable.

[mkae (Marko Käning)]

Committed with a few additions:

 * used suffixed "charm-qt5" as subport name
 * additional dependency to port qt[45]-mac-sqlite3-plugin

as r131841.

[RJVB (René Bertin)]

Replying to ryandesign@…:

• Why call github.setup with a commit hash? Why not use the 1.8.0 tag?

I'm not really familiar with git tags, and I *guess* that using a commit tag gives a potentially new snapshot of a given version.

Developers of most software projects commit changes to their software to their revision control system in logical chunks, called commits or revisions, and when they have finished a set of work they invent a new version number for the project, "tag" that version with a new version number, and release it to the world.

Really? :))

Sometimes developers release software very infrequently, and we may follow commits in that case, if we cannot convince the developers to adopt a more frequent release schedule.

That's what seems to be the case here. Same with QtCurve, btw.

local system, so if you retry a build, you don't need to download the distfile each time. If you use fetch.type git, you indicate that you want to forgo all those advantages and communicate directly with the underlying git repository every time you build a port. There are some situations where that is needed, some examples of which are given in the comments in the github portgroup, but when it is not needed, it should be avoided.

Hmmm, if github can serve a tarball of a given commit, then yes, that's by far to be preferred above repeated checkouts. For my local ports I don't use the github portgroup, but use a git.url that points to a local working copy that I, not MacPorts, keep up to date. (And that also serves me to isolate patches to be submitted to a review board or committed).

The most common reason to need quotes is if you are including whitespace in the variable's value, although even then it's only needed when dealing with pure variables (i.e. those you set with the Tcl command set), not MacPorts "options", which are a more advanced kind of variable.

I've run into cases where quotes were needed to prevent Tcl from interpreting an expression (without spaces) as a variable.