#16055: TeXworks -- TeX previewer for Mac OS X -- uses the Qt4 GUI framework --------------------------------------+------------------------------------- Reporter: jens.traube@t-online.de | Owner: macports-tickets@lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Submissions Component: ports | Version: 1.6.0 Resolution: | Keywords: tex, latex, editor, qt4 --------------------------------------+------------------------------------- Comment (by raimue@macports.org): Replying to [comment:5 jens.traube@t-online.de]:
== (1) Why is the version empty? ==[[BR]]
In the subversion repository there still is no release branch. The "TeXworks" project is still in it's infancy, Jonathan Kew call it a pre- release version. As I know, he first presented it on a conference in Bachotek, Poland, (April 30 to May 4, 2008 -- multimedia recordings of the talks: [http://www.river-valley.tv/conferences/bachotex2008/]).
I think, it would be to early to select a specific subversion revision number. Therefore, I suggest a "dynamic" version number: It consists of the date of the last commit and the number of that revision (HEAD). If you leave the variable "svn.tag" empty, you get the latest revision out of the subversion repository (revision "HEAD"). [...] [...] Perhaps my port should be named "TeXworks-devel" ?
The problem with always using HEAD is that it is untested. So you release a versions for end-users here which was tested by nobody. HEAD may not compile at all, HEAD may have major bugs etc. So I personally would prefer to tie it to one specific svn revision which is known to compile and was tested by the maintainer. Building from HEAD is just not realiable.
== (4) svn arguments ==[[BR]]
The synopsis of the svn checkout command is:
svn checkout URL[@REV]... [PATH]
The manual of svn tells that, if "PATH" is omitted, the basename of the URL will be used as the destination. The URL of TeXworks is:
svn.url http://texworks.googlecode.com/svn/trunk/
Therefore, the svn command would create a directory named "trunk". This is ok, and "svn.post_args-append" is really not necessary. But the variable "worksrcdir" must be set to this name: "trunk". The default value of variable "worksrcdir" is ${distname}, which is undefined with a svn fetch, I think.
Ah, I see. ${distname} is ${name}-${version} by default and is independent of `fetch.type`.
Also "svn.pre_args-append" is not necessary, but in the debug mode of macports the checkout procedure echoes all transmitted file names to the standard output.
Hm, sounds good, I will look into adding something like this as default. Leave this as it is for now.
== (5) What is the purpose of the post-fetch phase? ==[[BR]]
The purpose is to make the missing value of variable "version". It is the "dynamic" version number of TeXworks, about what I told you under (1) "Why is the version empty?".
Ah! Now I understand it. Looked like debug output only for me at first.
== (6) Don't use `cd` in the Portfile ==[[BR]]
But it is necessary to change to the directory ${worksrcpath}, what else can I do?
Use absolute path names like ${worksrcpath}/foo. I wrote a little [wiki:FAQ#Whywasthecdcommandremovedfromtrunk FAQ entry] about this.
== (7) Is this code for determining MACOSX_DEPLOYMENT_TARGET really needed? ==[[BR]]
Once again, I made a test in "post-patch": [...] It outputs nothing, is there something wrong with my test?
Sorry, unfortunately this default value is only available in trunk, but not in 1.6.0. MacPorts base uses `set macosx_version [expr 10.0 + ($os_major - 4) / 10.0]` to determine the version of Mac OS X. May be shorter as what you have now and can be replaced with `macosx_deployment_target` later anyway.
== (10) Please file a separate ticket for the wrong paths in the pkg- config files for qt4-mac as this needs to be fixed. Would be good to add a ticket number for reference so this workaround can be removed once it is fixed. ==[[BR]]
See Ticket #16120
Thanks! With the only concern being the version thing as noted above, I have no other objections to commit this port after #16056 has been resolved. You did a good job in putting this Portfile together, are you willing to become the maintainer of this port? -- Ticket URL: <http://trac.macports.org/ticket/16055#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS