February 2007 - macports-dev - lists.macosforge.org

Re: [22007] portutil.tcl mods / more portfile.7 changes needed?
by Mark Duling 14 Feb '07

14 Feb '07

macports-dev(a)lists.macosforge.org on Tuesday, February 13, 2007 at 7:09 PM -0800 wrote: >Reimplement delete so it no longer uses system "/bin/rm -rf ..." >This also fixes the case of filenames with spaces in them being >incorrectly parsed - That was EXTREMELY dangerous >Add new touch command - usage similar to BSD touch >Add new copy and move commands - basically aliases for file copy/rename >Add new ln command - usage similar to BSD ln >These should be documented somewhere I might be able to find time to document this. Especially because as I think about it there are still a couple of glaring omissions from our docs. I've written many portfiles and I still don't know the answer. Is there a way to do recursive copies without using a system call? I know how to use glob and recurse files within a directory, but I'm still not clear on whether it can be done for arbitrary contents of a directory. It seems not. So perhaps more portfile.7 manpage work is needed to answer these questions. They all revolve around globbing or recursion. 1) The use of 'glob'. It is missing from the manpages, is it not? Also provide liberal examples in the reinplace section and xinstall section. 2) Is it possible for reinplace to replace multiple strings for the same file with one statement? 3) The answer to whether generic recursive queries can be accomplished with TCL extensions. 3a) If the answer is no but a generic TCL script can be wrapped around xinstall using globs, then an example be given for doing this. If neither 3 or 3a is possible, state that system calls for recursive copies are acceptible. If someone can answer these questions adequately I may be able to find time to document this in portfile.7. It should be pretty simple and I think it would clear up some confusion. Mark

3 6

Spacing issues
by Kevin Ballard 13 Feb '07

13 Feb '07

The spacing in MacPorts is a bit non-standard. We have mostly tabs, but there's a bunch of spaces in there as well, and it causes for some interesting indentation. I propose that all future edits be standardized at either 2-width or 4-width soft tabs (as in, spaces). I'd even be willing to convert all existing tcl files to use spaces instead of tabs in one batch, though that could leave indentation issues (but those can be fixed by hand the next time the file is edited). Is there any reason to keep tabs? Or any other comments? -- Kevin Ballard http://kevin.sb.org eridius(a)macports.org http://www.tildesoft.com

7 18

file delete -force not deleting everything
by Blair Zajac 13 Feb '07

13 Feb '07

On 10.3.9, but not 10.4, the db44 port doesn't build with this error: Installing documentation: /bztmp/MacPorts/var/db/dports/build/_bztmp_MacPorts_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_databases_db44/work/destroot/bztmp/MacPorts/share/db44-4.4.20/ ... DEBUG: Executing proc-post-com.apple.destroot-destroot-0 Error: Target com.apple.destroot returned: error deleting "/bztmp/MacPorts/var/db/dports/build/_bztmp_MacPorts_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_databases_db44/work/destroot/bztmp/MacPorts/share/db44-4.4.20/api_c": file already exists Warning: the following items did not execute (for db44): com.apple.activate com.apple.destroot com.apple.install Error: Status 1 encountered during processing. Doing a ktrace shows this: 19629 tclsh8.4 CALL lstat(0x69bc08,0xbfff9b30) 19629 tclsh8.4 NAMI "/bztmp/MacPorts/var/db/dports/build/_bztmp_MacPorts_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_databases_db44/work/destroot/bztmp/MacPorts/share/db44-4.4.20/api_c/memp_openfd.html" 19629 tclsh8.4 RET lstat 0 19629 tclsh8.4 CALL unlink(0x69bc08) 19629 tclsh8.4 NAMI "/bztmp/MacPorts/var/db/dports/build/_bztmp_MacPorts_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_databases_db44/work/destroot/bztmp/MacPorts/share/db44-4.4.20/api_c/memp_openfd.html" 19629 tclsh8.4 RET unlink 0 19629 tclsh8.4 CALL getdirentries(0xc,0x1807e00,0x1000,0x313884) 19629 tclsh8.4 RET getdirentries 0 19629 tclsh8.4 CALL lseek(0xc,0,0,0) 19629 tclsh8.4 RET lseek 0 19629 tclsh8.4 CALL close(0xc) 19629 tclsh8.4 RET close 0 19629 tclsh8.4 CALL rmdir(0x69bc08) 19629 tclsh8.4 NAMI "/bztmp/MacPorts/var/db/dports/build/_bztmp_MacPorts_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_databases_db44/work/destroot/bztmp/MacPorts/share/db44-4.4.20/api_c" 19629 tclsh8.4 RET rmdir -1 errno 66 Directory not empty And doing an ls in there shows all the files after memp_openfd.html. This is generated by this line in the Portfile post-destroot { file delete -force ${destroot}${prefix}/share Has anybody seen anything like this before? Is the "file delete" an operation provided by Tcl? It's odd that it would go through and try to delete everything, but not finish the job. I'm tempted to change the "file delete -force" into a system "rm -fr ..." call. Regards, Blair

6 7

Fwd: [21973] trunk/dports/java/hibernate3/Portfile
by Juan Manuel Palacios 13 Feb '07

13 Feb '07

Hey Kevin! Could I ask you to please take a look at this last commit of mine? You think your recent clean up in trunk/base/ might have something to do with these empty depends_lib lines causing indexing to fail? I can't think of anything else since you're practically the only one hacking on base at the moment (and a big woot for being so brave! ;-) Regards,.. -jmpp Begin forwarded message: > From: source_changes(a)macosforge.org > Date: February 12, 2007 6:09:23 PM GMT-04:00 > To: macports-changes(a)lists.macosforge.org > Subject: [21973] trunk/dports/java/hibernate3/Portfile > Reply-To: macports-dev(a)lists.macosforge.org > > Revision > 21973007-02-12 14:09:23 -0800 (Mon, 12 Feb 2007) > > Log Message > Cleaning another emtpy depends_lib line. This Portfile was last > updated back in December and hadn't failed indexing > until today, which clearly means something new in svn TOT is choking > with these empty lines. Though I do like this > stricter checking, I believe this matter should be looked into. > > Modified Paths > • trunk/dports/java/hibernate3/Portfile > > Diff > > Modified: trunk/dports/java/hibernate3/Portfile (21972 => 21973) > --- trunk/dports/java/hibernate3/Portfile 2007-02-12 22:05:04 > UTC (rev 21972) > +++ trunk/dports/java/hibernate3/Portfile 2007-02-12 22:09:23 > UTC (rev 21973) > @@ -29,7 +29,6 @@ > bin:ant:apache-ant \ > bin:antlr:antlr \ > port:junit > -depends_lib > > use_configure no > > > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes

2 2

Re: Proposal: variants naming conventions
by Emmanuel Hainry 13 Feb '07

13 Feb '07

> I have noticed that most variants add or delete a configure flag in the form of --enable-*/--disable-*/--with-*/--without-* and maybe add or delete a related dependency. :> :> Therefore, I propose that all variants should fit the following forms: :> :> {en|dis}able_package: If a ported software package has optional compile-time features, the user can give configure command line options to specify whether to compile them. The options have one of these forms: :> --enable-feature :> --disable-feature :> (Note that this is slightly different then how configure scripts work[1]). :> :> with[out]_package: When a port requires, or can optionally use, other ports that can be or already are installed. The user can give configure command line options to specify which such external software to use. A port can be written with options have one of these forms: :> +with_package :> +without_package :> (Note that this is slightly different then how configure scripts work[2]). :> :> (Most configure scripts allow these options to passed with further information in the form of --option=arg where a reasonable default is set if =arg is not specified. port can't handle that, so =arg is not allowed in variant names and this proposal does not contemplate changing that) :> :> Changing this variant structure has, I believe, the following benefits: :> :> 1) Adding the verb enable/disable/use/with/without makes the variant more meaningful to users. I know there have been comments on the mailing list about the inability to comment on variants such that 'port info' is capable of explaining what each variant does. The verb will help address those complaints. :> :> 2) There are currently variants no-*, no_*, and no* These are inconsistent and do not tell me (the user) if I am disabling a feature (that some other port may depend on) or simply building the port without using some other package. :> :> 3) Negative variants are confusing. with_*/without_* or enable_*/ disable_* is more readable than +*/-* as an indicator of what is going on. :> :> References: :> [1] GNU Autoconf Manual Section 12.2: Choosing Package Options, http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/ autoconf.html#SEC131 :> [2] GNU Autoconf Manual Section 12.1: Working With External Software, http://www.gnu.org/software/autoconf/manual/autoconf-2.57/ html_mono/autoconf.html#SEC130 :> So, if I understand correctly, you want to get rid of negative variants (they do not get upgraded correctly) and not use the 'no' prefix for it is not always used the same way. In order to do that, you propose to stick to the convention of configure... Let me point a few things: 1) not all programs use configure, and those that do do not always use the autoconf standard. 2) as already pointed, some variants are not related to options in the configure but to which tools to use (choosing between gnu or bsd, choosing between the plethora of postgresql or the numerous mysql) 3) the +without_bidule does not feel logical to me: + is for adding something, without to tell that this addition is negative... 4) configure is generally a mess (to me): I have never well understood why with more that enable or the contrary. 5) longer variants names increases the probability of typos when trying to install a port (and there is no automatic completion of variants) as an example, at the moment, I have vim installed with variants +aqua +huge +ncurses +perl +python -ruby (I know the -ruby is unneeded) With this convention, it would be +enable_gui_carbon +with_features_huge +with_ncurses +enabel_perlinterp +enabel_pythoninterp +disable_rubyinterp Last point, you want to make default variants more widely used. default variants are a good mechanism, but they are not easy to grasp: I have installed lftp +ssl -tls. The only way I had to understand why port was insistng on building gnutls even when I tried 'port install lftp +ssl' and I saw in the portfile that ssl was conflicting with tls was to do a 'port cat lftp | grep tls'. the feature request here would be that 1. port info lists the default variants 2. port info port +variant takes variant into account to list the variant to be installed and also the dependencies. Emmanuel

1 0

Active committers on base/ ?
by Kevin Ballard 13 Feb '07

13 Feb '07

Who here is actively modifying, or considering modifying, base/? I ask because, in order to resolve the Spacing issue, we need to simply make a decision one way or the other and stop debating it. And frankly, this is only going to affect people who actually modify base/, which means it's worth knowing who is or will be doing this in order to figure out who this change will affect. As for me, yes, I'm working on base/. -- Kevin Ballard http://kevin.sb.org eridius(a)macports.org http://www.tildesoft.com

3 2

possible to fetch sources from git repository?
by Olaf Foellinger 12 Feb '07

12 Feb '07

Hi, on the GCompris mailing list Yeves Combe announced that he has not only compiled GCompris on Mac OS X but also has used the gtk+ aqua port. It shoud be possible to provide some portfiles to make these results available to mapcports. Some of the sources are only available in git repositories so the question arise whether it is possible to fetch sources from git repositories? The man page only mentions cvs repositories. Gruss Olaf

4 3

Re: Revamping home page left sidebar
by Jordan K. Hubbard 12 Feb '07

12 Feb '07

I know, I've already filed a bug report on that with Kevin. Both macports and webkit SHOULD have cnames, it's merely an oversight that they do not. - Jordan On Feb 12, 2007, at 1:07 AM, Kevin Ballard wrote: > May I point out that macports.macosforge.org isn't a working > domain? At the moment I see no way to be "at macosforge" when > perusing the MacPorts project site. > > On Feb 12, 2007, at 1:25 AM, Jordan K. Hubbard wrote: > >> That's largely for legacy reasons, but it's also allowed because >> it's under a different banner. I know that www.macports.org >> points to the equivalent of macports.macosforge.org right now, but >> since "macports.org" is notionally an independent site, there's >> nothing which disallows the project from establishing its own >> www.macports.org portal and having two different project faces, >> one at www.macports.org and one at macports.macosforge.org. It's >> only when people are "at macosforge" that they need to see a >> consistent L&F in order to meet Apple's style guidelines for >> macosforge. > > -- > Kevin Ballard > http://kevin.sb.org > kevin(a)sb.org > http://www.tildesoft.com > >

2 1

Re: Revamping home page left sidebar
by Ryan Schmidt 12 Feb '07

12 Feb '07

On Feb 11, 2007, at 23:30, Jordan K. Hubbard wrote: > On Feb 11, 2007, at 1:41 PM, Ryan Schmidt wrote: > >> By total coincidence, I see the mailing lists are available under >> the menu item "About Us." I would change that menu item to >> "Mailing Lists." >> >> Also, I would remove the links to other Mac OS Forge projects, >> unless having them there is a requirement of the deal. >> >> The MacPorts web site seems to have the standard Mac OS Forge >> "look." Is this required by the deal, or can it be changed to >> something completely different? I don't like the default Mac OS >> Forge theme. > > All Mac OS Forge projects have to have a consistent look and feel, > so there's not a whole lot of leeway for change on the project page > itself, but changing "Source Code" to "Downloads" and having a link > for "Mailing Lists" seem to be reasonable requests. I'll look into > getting those sidebar changes made. But the WebKit web site looks different from the rest of Mac OS Forge...

3 2

Update gmtl port
by Doug McCorkle 12 Feb '07

12 Feb '07

Hello, http://trac.macosforge.org/projects/macports/ticket/11332 Could this patch be applied? Thanks. Doug Doug McCorkle - Research Assistant Iowa State University Virtual Engineering Research Group www.vrac.iastate.edu/~mccdo

2 1