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

New port for glewpy
by Giulio Eulisse 15 Apr '07

15 Apr '07

Ciao, I've created a port for glewpy. See: https://svn.macosforge.org/projects/macports/ticket/11781 Ciao, Giulio

1 0

Is using TclX acceptable?
by Elias Pipping 15 Apr '07

15 Apr '07

I'll begin with a story - scroll down to the part with exclamation marks in front if you're in a hurry Working on openssl +universal, I needed a file list. It'd have to consist of all the single-arch files (except for the .o files) that end up in the worksrcdir once compiling for a single architecture has finished. It'd also come into play when lipo is called. See below for the two procedures (you can skip that part if you're only interested in what this mail is about, not the details) proc backup {arch} { global archList fileList workpath lappend archList ${arch} foreach fullPath ${fileList} { regexp {(.+/)([^/]+)} ./$fullPath dummy filePath fileName xinstall -d ${workpath}/${arch}/${filePath} xinstall ${fullPath} ${workpath}/${arch}/${filePath} } } proc lipo {} { global archList fileList workpath foreach fullPath ${fileList} { regexp {(.+/)([^/]+)} ./$fullPath dummy filePath fileName xinstall -d ${filePath} file delete ${fullPath} set lipoSources "" foreach a $archList { append lipoSources "-arch ${a} ${workpath}/${a}/${fullPath} " } system "lipo ${lipoSources}-create -output ${fullPath}" } } What i did to get such a list, worked, but it wasn't pretty. I inspected the directory manually, looking for archives (.a), libraries (.dylib, .so) and tests. The list I ended up with was created through globbing and explicitly adding files to it (see below) set binList "apps/openssl" set enList [glob engines/*.so] set libList [glob lib*.a lib*.*.*.*.dylib] set testList [concat test/sha256t test/sha512t [glob test/*test]] global fileList set fileList [concat $binList $enList $libList $testList] As I said before, this is horrible. Instead of creating such a list manually I though 'why note automate it?'. In bash it's easy - find files and check their file type (with /usr/bin/find and /usr/bin/file), see below: for i in `find * \! -name \*.o`; do if [ `$FILE $i | $EGREP -c "(Mach-O|ar archive)"` -gt 0 ] then echo $i fi done; (thanks to Eric Hall for pointing the '\! -name \*.o' syntax out to me) It's harder to have that in tcl. Tcl has globbing but globbing is *not* recursive. I've found recursive globbing in tcl, though[1]. globrecur.tcl is part of TclX (BSD license). It even comes with Mac OS X: /System/Library/Tcl/tclx8.4/globrecur.tcl ! So, the question is, can I savely depend on ! globrecur.tcl? If not, would it be possible to ! somehow include the file in the MacPorts ! distribution (it's under the BSD license after all) [1] http://tclx.cvs.sourceforge.net/*checkout*/tclx/tclx/library/ globrecur.tcl?revision=1.1 Regards, Elias

6 8

Re: [23888] trunk/base/src/port1.0/portlivecheck.tcl
by Paul Guyot 15 Apr '07

15 Apr '07

On Apr 12, 2007, at 8:54 PM, source_changes(a)macosforge.org wrote: > Revision: 23888 > http://trac.macosforge.org/projects/macports/changeset/23888 > Author: eridius(a)macports.org > Date: 2007-04-12 04:54:10 -0700 (Thu, 12 Apr 2007) > > Log Message: > ----------- > Fix livecheck to check for master_sites properly. > If a portfile isn't set up for livecheck and isn't a sourceforge/ > freshmeat project, default to none, not freshmeat (which would > cause a failure). > Clean up some if checks to avoid unnecessary syntax and > Revision: 23889 > http://trac.macosforge.org/projects/macports/changeset/23889 > Author: eridius(a)macports.org > Date: 2007-04-12 04:55:42 -0700 (Thu, 12 Apr 2007) > > Log Message: > ----------- > Make the up-to-date message for livecheck be info, not debug Hello Kevin, As I understand it, in addition to fixing and cleaning the code, you changed the semantics of livecheck significantly (without modifying the documentation). Previously, livecheck would: - report an error if it didn't work - default to freshmeat if nothing was set - be silent if the port was up to date Now, livecheck will: - report an error if it didn't work - be silent if nothing was set - report if the port was up to date The old observed behavior when everything was ok (nothing was displayed) now means that nothing was checked, which is quite a problem if the goal of a maintainer is to keep their ports up to date. The advantage of the original semantics is that it drives port maintainers to write livecheck for their ports, while setting a good default so that most ports don't need a specific livecheck. Basically, you livecheck your ports and any output means that you have to do something, shall it implement a specific livecheck because default doesn't work or update because the port was updated upstream. What argument do you have in favor of this change of semantics? Can we decide on reverting to the previous behavior? Paul

2 2

Getting to 1.4.1.
by James Berry 14 Apr '07

14 Apr '07

In an effort to expedite small releases of MacPorts, such as 1.4.1, I'd like to suggest that we keep trunk as usable as possible, whenever we can. As an example, it's been suggested that the universal variant support in trunk is relatively immature, while most of the other changes in trunk would be ready for release. May I suggest that we put in ./ configure --with-universal-variant or a ports.conf setting to to disable the effect of that variant? This would achieve two things, I believe: * Remove the threat of this option from trunk, while still allowing development and testing of the feature to continue on trunk. * Allow easy merging/tagging of 1.4.1 based on a complete merge from trunk. In general, this should allow us to quickly/easily tag minor revs so that we can keep up the pace of development and innovation. Thoughts? James

3 4

Boost multithreading
by Sean Fulton 14 Apr '07

14 Apr '07

Has anyone tried building the boost libraries with multithreading enabled? Sean

1 0

Re: [23965] trunk/dports/PortIndex
by Ryan Schmidt 13 Apr '07

13 Apr '07

This livecheck.distname stuff doesn't work: On Apr 13, 2007, at 14:34, source_changes(a)macosforge.org wrote: > Total number of ports parsed: 3876 > Ports successfully parsed: 3871 > Ports failed: 5 > > > Failed to parse file fuse/fusefs/Portfile: invalid command name > "livecheck.distname" > Failed to parse file fuse/libfuse/Portfile: invalid command name > "livecheck.distname" > Failed to parse file fuse/spotlightfs/Portfile: invalid command > name "livecheck.distname" > Failed to parse file fuse/sshfs/Portfile: invalid command name > "livecheck.distname" > Failed to parse file fuse/sshfs-gui/Portfile: invalid command name > "livecheck.distname"

2 1

Re: Ports that install binaries
by Ryan Schmidt 13 Apr '07

13 Apr '07

I'll continue this discussion on the dev list, where I probably should have started it in the first place. On Apr 13, 2007, at 01:18, Cédric Luthi wrote: > On 13 avr. 07, at 03:11, Ryan Schmidt wrote: > >> Are there any ports that install binaries? I mean, any ports that >> don't compile things themselves, but which download binaries and >> just install them? > > perforce does it, you might want to have a look at it. True... Thanks... I guess what I should have asked is if there were any ports that download disk images and install their contents, since that's a bit more complicated. I know MacPorts knows how to extract files from .tar.gz and .tar.bz2 archives, but I'm wondering if there's anything in place for .dmg files. Grepping all portfiles for "dmg" I only see one -- abiword -- which lets you choose either to compile from source or install a binary from a disk image. For the latter, it looks like this: variant use_binary conflicts use_source { distname AbiWord-${version}-10.2 extract.suffix .dmg.gz master_sites http://www.abisource.org/downloads/abiword/$ {version}/MacOSX checksums md5 13d249d7f0181a5c44e7342b302b19ae use_bzip2 no extract.post_args > ${workpath}/${distname}.dmg post-extract { file mkdir /tmp/${name}-${version} system "hdiutil attach ${workpath}/${distname}.dmg -private - nobrowse -mountpoint /tmp/${name}-${version}" } patch {} use_configure no build {} destroot { file mkdir ${destroot}/Applications/MacPorts file copy /tmp/${name}-${version}/AbiWord.app ${destroot}/ Applications/MacPorts } post-destroot { system "hdiutil detach /tmp/${name}-${version}" file delete -force /tmp/${name}-${version} } } So it calls hdiutil directly. Is that how I should do it? Or are there any built-in MacPorts commands for dealing with disk image distributions?

2 1

gmime now unmaintained
by Elias Pipping 13 Apr '07

13 Apr '07

I sent a mail to Sergo Trejo (sergtrejo(a)gmail.com, maintainer of gmime) yesterday, inquiring if he was still active. The reply I got today was [...] I'm not longer active. I wonder if someone else can take over for me? I've set the port to nomaintainer@ in r23957.

1 0

When a port is already universal
by Ryan Schmidt 13 Apr '07

13 Apr '07

Sorry for bringing up the "universal" subject again. But here it is. I just added a port for "sleepwatcher" which builds using Xcode, and it turns out that it builds a universal binary all by itself, without me asking it to or doing anything special. So I would like the "universal" variant to be auto-selected when anyone installs this port (so that, in the list of installed ports, one sees that this port is universal). I made this happen by adding this to the port: default_variants +universal variant universal {} This is probably sufficient, I think, but it's a situation we may not have thought of yet -- a port that is already universal. There had been talk before of adding a flag like "universal_ok yes" or "universal_ok no" to indicate that the default universal variant works or does not work. Perhaps we also want an option "is_already_universal yes" that we could specify, to replace the two above lines. Or perhaps that's not necessary. I just wanted to make people aware of this situation and solicit input. The other related situation is that when I install MacPorts 1.5.0 from trunk and run portindex and ask for info about sleepwatcher, I get: $ port info sleepwatcher sleepwatcher 2.0.4, sysutils/sleepwatcher (Variants: universal, universal) That is, it shows that the universal variant is available twice. Presumably one is the default universal variant, and the other is my own. I say that when a port provides its own universal variant, the MacPorts default universal variant should disappear. It's confusing to see two variants of the same name.

1 1

autoconf and perl
by Jann Röder 11 Apr '07

11 Apr '07

Hi all, I just discovered, that autoconf depends on the perl port. Is it really necessary to depend on the port instead of just the apple provided perl binary? I think a little tool like autoconf should't depend on a big port like perl, if it is not strictly necessary. Jann

1 0