/Library/Frameworks violates layout

Randall Wood rhwood at mac.com
Tue Nov 6 02:05:36 PST 2007


On 6 Nov 2007, at 01:05, Juan Manuel Palacios wrote:

>
> 	So, do we have an agreement on this? Any objections to turning on  
> warnings against /Library/Frameworks in the upcoming MacPorts 1.6?  
> I support to move to discourage writing to that directory, gcc's -F  
> flag should allow any application needing a framework to look for  
> it under prefix, just as Anders makes it clean in his message. Any  
> reason why we *shouldn't* move our frameworks into prefix?

There are no reasons other than esthetics (I would prefer something  
like /Library/MacPorts/Frameworks, but like I said, thats merely an  
cosmetic concern). Go for it.

> 	And as for macports1.0, we can still rely on configure's --with- 
> tclpackage flag to place it inside prefix in customized installations.
>
> 	Regards,...
>
> -jmpp
>
>
> On Nov 4, 2007, at 6:30 AM, Anders F Björklund wrote:
>
>> Or actually it doesn't trigger a warning, but it should...
>>
>> Frameworks _should_ go into ${prefix}/Library/Frameworks
>> instead, just like the various Pythons do at the moment.
>> Tcl and Applications might require "workarounds"* due to
>> bugs/shortcomings in other software, but not Frameworks ?
>>
>> However, this does require that the -F flag is passed -
>> just like the -I and -L flags are being passed already:
>> (I have a patch for GCC 3.3.x, should it ever be needed,
>> GCC 4.x.y has framework support, at least for the params)
>>
>> CPPFLAGS += -F${prefix}/Library/Frameworks
>> LDFLAGS += -F${prefix}/Library/Frameworks
>>
>> # the Xcode setting is
>> FRAMEWORK_SEARCH_PATHS
>>
>> Prime violators are the libsdl*-framework ports, and
>> also (indirectly) everything that uses them as well...
>> Installing into /Library/Frameworks isn't any more "OK"
>> than installing into /usr/local/include,/usr/local/lib !
>>
>> Could this tree policy be changed for MacPorts 1.6.0 ?
>> --anders
>>
>>
>> * Preferrably the current /Library/Tcl/macports1.0 and
>>   /Applications/MacPorts would be symlinks to ${prefix}.
>>   But that doesn't work apparently, due to shortcomings
>>   in AppKit and Cocoa when using with Services/Xcode ?
>>
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo/macports-dev
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev



Randall Wood
rhwood at mac.com
http://shyramblings.blogspot.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."




More information about the macports-dev mailing list