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 ?
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>
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? 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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@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."
Randall Wood 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.
The main question here is whether we should add the prefix framework path to the default search, so that it is picked up automatically by ports trying to use the frameworks (just like -I and -L are adding the prefix search paths already)... ? /Library/MacPorts/Frameworks has the worst of both worlds, it still clutters /Library (outside of prefix) but is not in the default framework search path either (so you still need to add something to GCC / Xcode in order for them to find it properly) I'm not sure how much besides libsdl*-framework uses /Library, but probably some Xcode apps ? --anders
On Nov 6, 2007, at 7:45 AM, Anders F Björklund wrote:
Randall Wood 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.
The main question here is whether we should add the prefix framework path to the default search, so that it is picked up automatically by ports trying to use the frameworks (just like -I and -L are adding the prefix search paths already)... ?
I guess we can figure that out as we move forward with the change. If we see a bunch of -F flags leaking into our Portfiles maybe we can think of a set of suitable defaults in base that will spare us the -I & -L dance for frameworks.
/Library/MacPorts/Frameworks has the worst of both worlds, it still clutters /Library (outside of prefix) but is not in the default framework search path either (so you still need to add something to GCC / Xcode in order for them to find it properly)
Other than adding gcc flags to base/Portfiles, what really would worry me is breaking anything by moving frameworks into our prefix. That being sorted out, I'd say there's good consensus to move them. Regards,... -jmpp
Le 6 nov. 07 à 07:05, Juan Manuel Palacios a écrit :
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?
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
<snip>
Does --with-tclpackage add some tcl code to the beginning of the port executable to add the path to ${auto_path}? -- Anthony Ramine, the "Ports tree cleaning Maestro". <nox@macports.org>
On Nov 6, 2007, at 11:01 AM, N_Ox wrote:
Le 6 nov. 07 à 07:05, Juan Manuel Palacios a écrit :
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?
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
<snip>
Does --with-tclpackage add some tcl code to the beginning of the port executable to add the path to ${auto_path}?
Code is added to the port executable, yes, but only in the form of: ---------- (from trunk/base/src/port/Makefile) ---------- edit = sed \ -e 's,@TCLSH\@,$(TCLSH),g' \ -e 's,@TCL_PACKAGE_DIR\@,$(TCL_PACKAGE_DIR),g' ---------- ($(TCL_PACKAGE_DIR) being received from autoconf through --with- tclpackage) ---------- So that: ---------- (from trunk/base/src/port/port.tcl) catch {source \ [file join "@TCL_PACKAGE_DIR@" macports1.0 macports_fastload.tcl]} package require macports The result is that the port executable is able to load the macports1.0 package, wherever it's put by autoconf (/Library/Tcl being the default). But I don't know about ${auto_path}, I don't think anything about the tcl package is added to it; why are you interested in that? -jmpp
Le 6 nov. 07 à 17:51, Juan Manuel Palacios a écrit :
On Nov 6, 2007, at 11:01 AM, N_Ox wrote:
Le 6 nov. 07 à 07:05, Juan Manuel Palacios a écrit :
<snip>
Does --with-tclpackage add some tcl code to the beginning of the port executable to add the path to ${auto_path}?
Code is added to the port executable, yes, but only in the form of:
---------- (from trunk/base/src/port/Makefile) ---------- edit = sed \ -e 's,@TCLSH\@,$(TCLSH),g' \ -e 's,@TCL_PACKAGE_DIR\@,$(TCL_PACKAGE_DIR),g' ---------- ($(TCL_PACKAGE_DIR) being received from autoconf through --with- tclpackage) ----------
So that:
---------- (from trunk/base/src/port/port.tcl) catch {source \ [file join "@TCL_PACKAGE_DIR@" macports1.0 macports_fastload.tcl]} package require macports
The result is that the port executable is able to load the macports1.0 package, wherever it's put by autoconf (/Library/Tcl being the default). But I don't know about ${auto_path}, I don't think anything about the tcl package is added to it; why are you interested in that?
-jmpp
Oh, I didn't know macports_fastload.tcl, I was talking about $ {auto_path} because that's what I used to find macports1.0 package into ${prefix} in the patch I've submitted: http://trac.macports.org/ projects/macports/ticket/12943 -- Anthony Ramine, the "Ports tree cleaning Maestro". <nox@macports.org>
So, N_Ox, are we gonna see Frameworks moved inside ${prefix} for 1.6? If I recall correctly from our IRC conversation the other day, it's the Xcode PortGroup that needs to be tweaked for this path to change? Regards,.... -jmpp
Le 12 nov. 07 à 07:19, Juan Manuel Palacios a écrit :
So, N_Ox, are we gonna see Frameworks moved inside ${prefix} for 1.6? If I recall correctly from our IRC conversation the other day, it's the Xcode PortGroup that needs to be tweaked for this path to change?
Regards,....
-jmpp
There's a few other changes needed to make the move: - Change the default ${xcode.destroot.path} set by `xcode.destroot.type framework`. - Add "FRAMEWORK_SEARCH_PATH='${prefix}/Library/Frameworks:\$ (FRAMEWORK_SEARCH_PATH)'" to the default ${xcode.build.settings}. - Add "-F${prefix}/Library/Frameworks" to the default $ {configure.ldflags} and ${configure.cppflags}. At last but not least, there's a few xcode ports which default destroot stage fails to install the framework product and these are installed manually through `copy` TCL procedure, they will need to be modified accordingly. Regards, -- Anthony Ramine, the "Ports tree cleaning Maestro". <nox@macports.org>
participants (4)
-
Anders F Björklund
-
Juan Manuel Palacios
-
N_Ox
-
Randall Wood