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
We can't simply include the file, it depends on TclX-supplied readdir and cequal as well. So it's either allow all of TclX or none of it. On Apr 14, 2007, at 10:58 PM, Elias Pipping wrote:
! 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)
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On Apr 14, 2007, at 21:58, Elias Pipping wrote:
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)
Recall the "unify" script from the Mozilla project, which they use to create universal binaries of Firefox and other programs from a ppc tree and an i386 tree, and my suggestion some time ago that it might be a good idea to incorporate it into MacPorts. Would that be a possible solution to your problem, without having to reinvent that script in tcl?
On Apr 15, 2007, at 5:36 AM, Ryan Schmidt wrote:
Recall the "unify" script from the Mozilla project, which they use to create universal binaries of Firefox and other programs from a ppc tree and an i386 tree, and my suggestion some time ago that it might be a good idea to incorporate it into MacPorts. Would that be a possible solution to your problem, without having to reinvent that script in tcl?
I do, it wasn't written in tcl though (iirc). Regards, Elias
On Apr 14, 2007, at 22:43, Elias Pipping wrote:
On Apr 15, 2007, at 5:36 AM, Ryan Schmidt wrote:
Recall the "unify" script from the Mozilla project, which they use to create universal binaries of Firefox and other programs from a ppc tree and an i386 tree, and my suggestion some time ago that it might be a good idea to incorporate it into MacPorts. Would that be a possible solution to your problem, without having to reinvent that script in tcl?
I do,
it wasn't written in tcl though (iirc).
Right, it's not; my point was that I hope you're not trying to write routines in tcl that do the same thing as unify *just because* unify isn't in tcl [1]. I say unify is a mature and useful script, and if its license is compatible with ours (research still needed here), why not make use of it in MacPorts, regardless of what language it's in. Now, if unify is insufficient for our needs in some way, then that may be another story. But even then perhaps we should be thinking "Can I make a minor change to unify so it does what I want?" rather than "Can I write a whole new script that does what I want?" I think I'm trying to suggest that maybe unify should be part of MacPorts base, and that MacPorts base should provide a way to configure and build a port separately for each architecture, then unify it into a universal binary, with very little effort from the port author. One option would be for this mechanism to become the default way that a universal port is built. The advantage would be that we can use an earlier gcc and an earlier Mac OS X SDK for the ppc build, making it compatible with earlier Mac OS X versions on ppc. We could introduce new variables by which port authors can specify the Mac OS X version that should be used for each architecture. This would be used to set the MACOSX_DEPLOYMENT_TARGET variable correctly, to select the right Mac OS X SDK to use, and maybe even to pick the version of gcc. Or if support of differing Mac OS X versions for the ppc and i386 builds is not a goal we want to pursue, then the multiple-build-and- then-unify approach could be a secondary way to build universally which the port author could request in the case that the normal quick -arch ppc -arch i386 universal variant we have in trunk now doesn't work with a given software package (openssl, cairo, etc.) In this case, we could extend Paul's new "universal_variant" variable. Instead of "yes" and "no", it could have three values. I'm not sure what they should be called yet, but: 1) an option to configure, build and install everything in one go, using -arch ppc -arch i386 (this would be default, as it is now), 2) an option to configure and build separately for each arch and install into temporary directories, then unify the result into the destroot, and 3) no universal variant at all ("none", equivalent to "no" in Paul's current code). [1] http://en.wikipedia.org/wiki/Not_Invented_Here
On Apr 14, 2007, at 7:58 PM, Elias Pipping wrote:
I'll begin with a story - scroll down to the part with exclamation marks in front if you're in a hurry
I think there are three answers to your question (well, two answers to your specific question and an answer to a question you did not ask :-) 1. As Kevin has already pointed out, MacPorts is still stuck supporting Panther for now, so relying on the full feature set of the "Batteries Included Tcl" we started shipping with Tiger isn't going to work, as much as it would be nice. 2. Once Leopard is released, unless MacPorts is completely rewritten in Ruby or ${NewLanguageHotness}, I think leveraging more of the Batteries Included distribution would be a fine idea, and not because I'm trying to get Tcl even more deeply entrenched but because, let's face it, BI Tcl includes a lot of really nice functions that would make MacPorts code more powerful and concise if leveraged, so why not leverage it? If people don't, then I have to say that there was little point in including a more functional Tcl distribution by default. Other platforms, should they ever become truly significant targets for MacPorts, also support TclX so that's no barrier to entry either. So, I guess to answer your question directly: Yes, great idea, just not yet. To answer the question you didn't ask, namely: "What's the best way to implement something like a recursive glob function if other constraints keep me from using Tcl?" Write it in C and stick it in Pextlib. Sorry, I know that's an annoying answer, but it's how I'd do it. Including great big chunks of TclX instead (since, as Kevin also pointed out, it's fairly interdependent) would be a far less palatable alternative and far less self-contained than a simple C function added to base. - Jordan
On Apr 15, 2007, at 12:36 AM, Ryan Schmidt wrote:
In this case, we could extend Paul's new "universal_variant" variable. Instead of "yes" and "no", it could have three values. I'm not sure what they should be called yet
Yes No FileNotFound ;) -Kevin Ballard -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
participants (6)
-
David MacMahon
-
Elias Pipping
-
Jordan K. Hubbard
-
Kevin Ballard
-
Paul Guyot
-
Ryan Schmidt