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? Thanks, Cyrus -------------- next part -------------- A non-text attachment was scrubbed... Name: R-20050825-macos-build-install-fixes.patch Type: application/octet-stream Size: 1304 bytes Desc: not available Url : https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20050825/07adf6cf/R-20050825-macos-build-install-fixes.obj
(no subject)
4 messages · Simon Urbanek, Cyrus Harmon
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
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
On further review, I think #2 is also busted here. It should be putting the sources in PrivateHeaders not in PrivateHeaders/include. Whoops. Hate to be thinking out loud here, but we should probably only copy the *.h files from src/include (if those!) to PrivateHeaders. Here's a revised patch: -------------- next part -------------- A non-text attachment was scrubbed... Name: R-private-header-install-20050825b.patch Type: application/octet-stream Size: 1373 bytes Desc: not available Url : https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20050825/b0f3cd55/R-private-header-install-20050825b.obj -------------- next part -------------- Thanks, Cyrus
On Aug 25, 2005, at 2: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? Thanks, Cyrus <R-20050825-macos-build-install-fixes.patch>
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac