Hi Simon, Thanks for the update. Oh, and my apologies for sending the original (follow-up) email out without a subject.
In any case, it seems to me that the intention of the "-framework R" in etc/Makeconf is to be able to find _this particular_ R framework. The -F argument seems like a good way of doing that. I could see an argument for testing FRAMEWORK_DIR and not adding the -F if it's / Library/Frameworks/R.framework, but I'm hard pressed to see how the - framework R is useful except in the case when the framework is installed in /Library/Frameworks. I suppose I'm missing a couple of other places, including /System/Library/Frameworks and ~/Library/ Frameworks, but, still, it would seem to make sense to me to match an etc/Makeconf's -f arguments with the particular framework. By all means, if you guys have been down this road and think it's a bad idea, I'm all ears, but I wanted to make another push for this as I _really_ hate having dependencies on environment variables. I'd much prefer a properly (FSVO properly, of course) written config file that obviates the need for the environment var. Thanks again, Cyrus On Aug 25, 2005, at 5:05 PM, Simon Urbanek wrote: > Cyrus, > > On Aug 25, 2005, at 5:26 PM, Cyrus Harmon wrote: > > >> Dear r-sig-mac, >> >> I sent this patch to the r-devel list a week or so ago, but so far >> it hasn't made it into the tree. The patch fixes two things: >> >> 1. it puts -F$(R_FRAMEWORK_DIR)/.. in the LIBR line in etc/ >> Makeconf so that subsequent builds can find the framework if it is >> put somewhere besides /Library/Frameworks. >> >> 2. the install of the headers into $(R_FRAMEWORK_DIR)/Versions/ >> Current/PrivateHeaders) was taking the headers from $(srcdir) >> instead of $(top_builddir). The patch fixes this. The result of >> not fixing this is that the .svn directory gets copied to the >> framework PrivateHeaders dir. >> >> These both seem like useful things and I'd love to see them get >> into the tree. Besides posting here and in r-devel, whom should I >> pester? >> > > Basically me ;). > > It's on my ToDo list for review, because I'm not quite happy with > the part 1) yet. One argument is that you should set your > DYLD_FRAMEWORK_PATH if you plan to use non-standard location that > is not in the default search path. There are issues with non- > standard locations anyway as we have learned the hard way > (conflicts with system frameworks), so I want to be careful. But > thanks for re-posting, because I was in fact looking for your > original e-mail today (and couldn't find it in the hurry, because I > received it while traveling). > > Cheers, > Simon > > _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
