Le 4 nov. 07 à 11:30, Anders F Björklund a écrit :
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
I'd love that! Installing into /Library/Frameworks feels just plain wrong.
* 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 ?
As you know, ${prefix}/share/tcl/macports1.0 would be okay, we just need to add this path to the port executable, see http://trac.macports.org/projects/macports/ticket/12943 -- Anthony Ramine, the "Ports tree cleaning Maestro". <nox@macports.org>