/Library/Frameworks violates layout

Anders F Björklund afb at macports.org
Sun Nov 4 02:30:39 PST 2007


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 ?



More information about the macports-dev mailing list