[R-SIG-Mac] (no subject)

[Cyrus Harmon]

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
>
>