[MacPorts] #46575: submission of the Charm time tracker for Qt4 or Qt5

[MacPorts]

#46575: submission of the Charm time tracker for Qt4 or Qt5
--------------------------+--------------------
  Reporter:  rjvbertin@…  |      Owner:  mk@…
      Type:  submission   |     Status:  closed
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:  fixed        |   Keywords:
      Port:  Charm        |
--------------------------+--------------------

Comment (by rjvbertin@…):

 Replying to [comment:19 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/46575#comment:22>
MacPorts <https://www.macports.org/>
Ports system for OS X