/Library/Frameworks violates layout

[N_Ox]

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 at macports.org>