On Sun, Apr 27, 2014 at 12:22 AM, Casey Rodarmor <[email protected]> wrote: > On Saturday, March 15, 2014 9:59:33 PM UTC+1, [email protected] wrote: >> >> On Tue, Mar 11, 2014 at 12:10 PM, Casey Rodarmor <[email protected]> >> wrote: >>> >>> Hi there, >>> >>> I recently started using tup as an alternative to waf, and I'm very happy >>> with it. However there is one issue: It seems to be incompatible with OS X >>> resource forks. >>> >>> As part of a build step, I have to create and append to an object's >>> resource fork, but that fails under tup. I think it's because the filesystem >>> that tup instantiates for builds is not compatible with OS X resource forks >>> and extended attributes. Is that correct, and is there any way to work >>> around that? >>> >> >> Hi Casey, >> >> Can you give an example Tupfile here? I've not used resource forks before, >> so I'm not exactly sure what you're trying to do. >> >> Thanks! >> -Mike > > > Hi Mike, > > The command looks like this: > > : a.out |> cp a.out a.out.icon; Rez -append icon.rsrc -o a.out.icon |> > a.out.icon > > Rez is an OS X utility that modifies resource forks: > http://en.wikipedia.org/wiki/Resource_fork > > Resource forks are more trouble than they're worth, but they allow for > storing structured data in a file. They're kind of a legacy thing, and since > they need low-level support from the filesystem and utilities they cause > horrible interoperability problems with other operating systems and > non-resource fork aware tools. > > In the command above, I'm appending a file containing an icon, in resource > fork form, to a.out, so that it has a nice icon when I run it. The command > succeeds on the command line, but fails when run in a tupfile, with the > following output: > > ### /Applications/Xcode.app/Contents/Developer/usr/bin/Rez - SysError -54 > during create of "a.out.icon". > ### /Applications/Xcode.app/Contents/Developer/usr/bin/Rez - Fatal error > trying to open the resource file "a.out.icon" for writing. > Fatal Error! > ### /Applications/Xcode.app/Contents/Developer/usr/bin/Rez - Fatal Error, > can't recover. > ### /Applications/Xcode.app/Contents/Developer/usr/bin/Rez - Since errors > occurred, a.out.icon's resource fork was not completely updated. > ### /Applications/Xcode.app/Contents/Developer/usr/bin/Rez - SysError -43 > during set file info. > > My guess would be that the filesystem that tup creates isn't compatible with > resource forks for some reason.
There is no such incompatibility that I know of. The problem I see is that the above command uses a file, a.out.icon, for both input and output. Tup's file usage model is very primitive. A rule is allowed to use a file for only input or for only output. I suspect this simplifies the DAG because writing a file, reading it, and re-writing it, as you attempted above, makes the DAG more complex. It shouldn't be a problem, but it is. > This is probably not worth fixing at all if > I'm the only person who's been bothered by it. A normal human being in this > day and age of OS X would use application bundles to associate icons with > executables. It is not resource forks or OS X. It is Tup. -- Lee -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
