On Jun 30, 2007, at 14:40, Eloy Duran wrote:
On 6/30/07, Ryan Schmidt wrote:
On Jun 30, 2007, at 09:48, Eloy Duran wrote:
Second, I'm not allowed to use the universal variant because it's not a configure script based installation. Is there some way to override this? Because now I have a builduniversal variant, but this is not so nice...
It should suffice to just redefine the universal variant:
variant universal { configure.args-append --build-universal=yes }
Unfortunately it doesn't. Macports complains that the universal variant is only supported on "configure" based ports...
Don't forget to reply to all so that your reply goes to the list, too, and not just to me. Run the install in debug mode (sudo port -dv install). It's not complaining about your port; it's complaining about a different one. See my similar experience here: http://trac.macosforge.org/projects/macports/ticket/12170 If you'll tell us which port it's complaining about, we can disable its universal variant like I did in #12137 for XFree86. That will work around the problem.
Hello, Took a while, before I had some time again to play with this... First of, Ryan you were right that it was another port complaining about the universal variant. It was rb-hpricot, I added "universal_variant no" to the portfile which works great. Also rubygems has a problem with the universal variant, I added the following to the portfile to fix it: variant universal { configure.args-delete --disable-dependency-tracking } Is this the correct way to do it? One other thing I hadn't noticed earlier is that ruby itself does not work with the universal variant. I could of course also add "universal_variant no", but this will defeat the purpose of building rubycocoa as a universal.... So does anybody know if ruby is already being worked on? On another topic, I haven't yet heard back from the maintainer of the rubycocoa portfile. How do you guys deal with these kinds of issues? Is there a period or so after which a new maintainer could step in? Cheers, Eloy On 6/30/07, Ryan Schmidt <ryandesign@macports.org> wrote:
On Jun 30, 2007, at 14:40, Eloy Duran wrote:
On 6/30/07, Ryan Schmidt wrote:
On Jun 30, 2007, at 09:48, Eloy Duran wrote:
Second, I'm not allowed to use the universal variant because it's not a configure script based installation. Is there some way to override this? Because now I have a builduniversal variant, but this is not so nice...
It should suffice to just redefine the universal variant:
variant universal { configure.args-append --build-universal=yes }
Unfortunately it doesn't. Macports complains that the universal variant is only supported on "configure" based ports...
Don't forget to reply to all so that your reply goes to the list, too, and not just to me.
Run the install in debug mode (sudo port -dv install). It's not complaining about your port; it's complaining about a different one. See my similar experience here:
http://trac.macosforge.org/projects/macports/ticket/12170
If you'll tell us which port it's complaining about, we can disable its universal variant like I did in #12137 for XFree86. That will work around the problem.
On Jul 7, 2007, at 07:55, Eloy Duran wrote:
On 6/30/07, Ryan Schmidt wrote:
On Jun 30, 2007, at 14:40, Eloy Duran wrote:
On 6/30/07, Ryan Schmidt wrote:
On Jun 30, 2007, at 09:48, Eloy Duran wrote:
Second, I'm not allowed to use the universal variant because it's not a configure script based installation. Is there some way to override this? Because now I have a builduniversal variant, but this is not so nice...
It should suffice to just redefine the universal variant:
variant universal { configure.args-append --build-universal=yes }
Unfortunately it doesn't. Macports complains that the universal variant is only supported on "configure" based ports...
Run the install in debug mode (sudo port -dv install). It's not complaining about your port; it's complaining about a different one. See my similar experience here:
http://trac.macosforge.org/projects/macports/ticket/12170
If you'll tell us which port it's complaining about, we can disable its universal variant like I did in #12137 for XFree86. That will work around the problem.
First of, Ryan you were right that it was another port complaining about the universal variant. It was rb-hpricot, I added "universal_variant no" to the portfile which works great.
Ok, so either "universal_variant no" should be added to the rb- hpricot port, or the rb-hpricot port should be fixed so it can build universal. I'm Cc'ing Paul Guyot who maintains rb-hpricot.
Also rubygems has a problem with the universal variant, I added the following to the portfile to fix it:
variant universal { configure.args-delete --disable-dependency-tracking }
Is this the correct way to do it?
No. You have effectively made the port no longer attempt to build universal by doing that. Remember: when you write "variant universal {...}" in your portfile, you are *replacing* the default universal variant, which reads: variant universal { if {[tbool use_xmkmf] || ![tbool use_configure]} { return -code error "Default universal variant only works with ports based on configure" } configure.args-append ${configure.universal_args} if {![file exists /Developer/SDKs/MacOSX10.4u.sdk/]} { return -code error "MacOS X 10.4 universal SDK is not installed (are we running on 10.3? did you forget to install it?) and building with +universal will very likely fail" } configure.cflags-append ${configure.universal_cflags} configure.cppflags-append ${configure.universal_cppflags} configure.cxxflags-append ${configure.universal_cxxflags} configure.ldflags-append ${configure.universal_ldflags} } See portmain.tcl: http://trac.macosforge.org/projects/macports/browser/trunk/base/src/ port1.0/portmain.tcl The various universal_*flags are defined thus: default configure.universal_args --disable-dependency-tracking default configure.universal_cflags {"-isysroot /Developer/SDKs/ MacOSX10.4u.sdk -arch i386 -arch ppc"} default configure.universal_cppflags {} default configure.universal_cxxflags {"-isysroot /Developer/SDKs/ MacOSX10.4u.sdk -arch i386 -arch ppc"} default configure.universal_ldflags {"-arch i386 -arch ppc"} See portconfigure.tcl: http://trac.macosforge.org/projects/macports/browser/trunk/base/src/ port1.0/portconfigure.tcl What you probably want instead of "variant universal {...}" is: pre-configure { if {[variant_isset universal]} { configure.args-delete --disable-dependency-tracking } } That's assuming, of course, that it's really necessary to remove "-- disable-dependency-tracking". The reason it's there by default for +universal is that it's needed for most (all?) configure-based software when building universal. Now, rb-cocoa is in the ruby portgroup. These changes you're making to make it universal... might they also be relevant for the other ports in the ruby portgroup? If so, perhaps your changes, once you figure out how to build a ruby thing universal, should go into MacPorts base, rather than into each individual ruby-related portfile.
One other thing I hadn't noticed earlier is that ruby itself does not work with the universal variant. I could of course also add "universal_variant no", but this will defeat the purpose of building rubycocoa as a universal.... So does anybody know if ruby is already being worked on?
No idea. Have you already asked Paul? He's also the maintainer of the ruby port. Also, have you already built all of Ruby's dependencies universal? That would be the first required step.
On another topic, I haven't yet heard back from the maintainer of the rubycocoa portfile. How do you guys deal with these kinds of issues? Is there a period or so after which a new maintainer could step in?
The policy is that if you have changes you want made to a portfile, you file a ticket in Trac and attach a diff and assign it to the maintainer (if in the list) and Cc yourself and the maintainer. If the maintainer does not react within 72 hours, then you can email the list with the ticket number and request that someone else commit the change.
Hey Ryan & list,
Ok, so either "universal_variant no" should be added to the rb- hpricot port, or the rb-hpricot port should be fixed so it can build universal. I'm Cc'ing Paul Guyot who maintains rb-hpricot.
I tested hpricot from source and it's capable of building a universal binary. However it gets it's config from the ruby config, so when using a non-universal ruby it will definitely not build the C extension as a universal bin. So I've been focussing on ruby for now in the hope that I can patch mkmf.rb in such a way that any ruby C extensions that use extconf to create a Makefile will be build as universal binaries. However I'm not sure if all the binary gems are really build on the machine or are distributed as binaries, but I believe they only have binaries for mswin.
Also rubygems has a problem with the universal variant, I added the following to the portfile to fix it:
variant universal { configure.args-delete --disable-dependency-tracking }
Is this the correct way to do it?
No. You have effectively made the port no longer attempt to build universal by doing that. < *snip* What you probably want instead of "variant universal {...}" is:
pre-configure { if {[variant_isset universal]} { configure.args-delete --disable-dependency-tracking } }
That's assuming, of course, that it's really necessary to remove "-- disable-dependency-tracking". The reason it's there by default for +universal is that it's needed for most (all?) configure-based software when building universal.
Thanks, I was indeed simply killing the universal option :) Rubygems is not configure based software, it uses a pure ruby config script which doesn't take the --disable-dependency-tracking option. Actually I don't think any software in rubygems is anything other than pure ruby, so it doesn't really matter anyways....
Now, rb-cocoa is in the ruby portgroup. These changes you're making to make it universal... might they also be relevant for the other ports in the ruby portgroup? If so, perhaps your changes, once you figure out how to build a ruby thing universal, should go into MacPorts base, rather than into each individual ruby-related portfile.
My hope is that once I have a fully functional universal ruby and apply some patches to mkmf.rb that any ruby C extension will be build as universal binaries. Also through rubygems. There will of course always be exceptions to this....
One other thing I hadn't noticed earlier is that ruby itself does not work with the universal variant. I could of course also add "universal_variant no", but this will defeat the purpose of building rubycocoa as a universal.... So does anybody know if ruby is already being worked on?
No idea. Have you already asked Paul? He's also the maintainer of the ruby port. Also, have you already built all of Ruby's dependencies universal? That would be the first required step.
Ok, this is where I'm at. All the dependencies are universal binaries, these all worked out of the box with macports. I have succesfully patched the configure script to build a universal ruby with --enable-shared. I have patched mkmf.rb to correctly build extensions that might do any checks in there extconf, like zlib. The only extension that doesn't compile is the openssl one, I can only compile it as a i386 binary. However if I apply the macports patches (plus my own) and then configure it to use /usr, so where the apple supplied libs are then it compiles without a problem. I have put the openssl mkmf.log files for both situations online: macports libs: http://superalloy.nl/misc_files/macports/ruby/mkmf-opt-local.log apple libs: http://superalloy.nl/misc_files/macports/ruby/mkmf-usr.log As you can see the differences start to occur from: "have_library: checking for SSL_library_init() in -lssl...". Which returns yes for /usr but no for /opt/local. Also it says this in the log for /opt/local: /usr/bin/ld: warning can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/libz.1.dylib referenced from: /opt/local/lib/libcrypto.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) Uhmmmm..... Is this why it fails to build?? I mean that path can't be correct can it? But that path doesn't really seem to be in there so I don't think that's the cause: $ strings /opt/local/lib/libcrypto.0.9.8.dylib | grep Developer cc -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -fno-common -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 Could anybody offer any tips on where I should look??? I'm so close, it's getting frustrating! hahahahaha ;)
The policy is that if you have changes you want made to a portfile, you file a ticket in Trac and attach a diff and assign it to the maintainer (if in the list) and Cc yourself and the maintainer. If the maintainer does not react within 72 hours, then you can email the list with the ticket number and request that someone else commit the change.
Okidoki. Cheers, Eloy
The only extension that doesn't compile is the openssl one, I can only compile it as a i386 binary. However if I apply the macports patches (plus my own) and then configure it to use /usr, so where the apple supplied libs are then it compiles without a problem.
I should add that I am on a intel machine :) Eloy On 7/13/07, Eloy Duran <eloy.de.enige@gmail.com> wrote:
Hey Ryan & list,
Ok, so either "universal_variant no" should be added to the rb- hpricot port, or the rb-hpricot port should be fixed so it can build universal. I'm Cc'ing Paul Guyot who maintains rb-hpricot.
I tested hpricot from source and it's capable of building a universal binary. However it gets it's config from the ruby config, so when using a non-universal ruby it will definitely not build the C extension as a universal bin.
So I've been focussing on ruby for now in the hope that I can patch mkmf.rb in such a way that any ruby C extensions that use extconf to create a Makefile will be build as universal binaries. However I'm not sure if all the binary gems are really build on the machine or are distributed as binaries, but I believe they only have binaries for mswin.
Also rubygems has a problem with the universal variant, I added the following to the portfile to fix it:
variant universal { configure.args-delete --disable-dependency-tracking }
Is this the correct way to do it?
No. You have effectively made the port no longer attempt to build universal by doing that. < *snip* What you probably want instead of "variant universal {...}" is:
pre-configure { if {[variant_isset universal]} { configure.args-delete --disable-dependency-tracking } }
That's assuming, of course, that it's really necessary to remove "-- disable-dependency-tracking". The reason it's there by default for +universal is that it's needed for most (all?) configure-based software when building universal.
Thanks, I was indeed simply killing the universal option :)
Rubygems is not configure based software, it uses a pure ruby config script which doesn't take the --disable-dependency-tracking option. Actually I don't think any software in rubygems is anything other than pure ruby, so it doesn't really matter anyways....
Now, rb-cocoa is in the ruby portgroup. These changes you're making to make it universal... might they also be relevant for the other ports in the ruby portgroup? If so, perhaps your changes, once you figure out how to build a ruby thing universal, should go into MacPorts base, rather than into each individual ruby-related portfile.
My hope is that once I have a fully functional universal ruby and apply some patches to mkmf.rb that any ruby C extension will be build as universal binaries. Also through rubygems. There will of course always be exceptions to this....
One other thing I hadn't noticed earlier is that ruby itself does not work with the universal variant. I could of course also add "universal_variant no", but this will defeat the purpose of building rubycocoa as a universal.... So does anybody know if ruby is already being worked on?
No idea. Have you already asked Paul? He's also the maintainer of the ruby port. Also, have you already built all of Ruby's dependencies universal? That would be the first required step.
Ok, this is where I'm at. All the dependencies are universal binaries, these all worked out of the box with macports. I have succesfully patched the configure script to build a universal ruby with --enable-shared. I have patched mkmf.rb to correctly build extensions that might do any checks in there extconf, like zlib.
The only extension that doesn't compile is the openssl one, I can only compile it as a i386 binary. However if I apply the macports patches (plus my own) and then configure it to use /usr, so where the apple supplied libs are then it compiles without a problem.
I have put the openssl mkmf.log files for both situations online: macports libs: http://superalloy.nl/misc_files/macports/ruby/mkmf-opt-local.log apple libs: http://superalloy.nl/misc_files/macports/ruby/mkmf-usr.log
As you can see the differences start to occur from: "have_library: checking for SSL_library_init() in -lssl...". Which returns yes for /usr but no for /opt/local. Also it says this in the log for /opt/local: /usr/bin/ld: warning can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/libz.1.dylib referenced from: /opt/local/lib/libcrypto.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)
Uhmmmm..... Is this why it fails to build?? I mean that path can't be correct can it? But that path doesn't really seem to be in there so I don't think that's the cause:
$ strings /opt/local/lib/libcrypto.0.9.8.dylib | grep Developer cc -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -fno-common -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386
Could anybody offer any tips on where I should look??? I'm so close, it's getting frustrating! hahahahaha ;)
The policy is that if you have changes you want made to a portfile, you file a ticket in Trac and attach a diff and assign it to the maintainer (if in the list) and Cc yourself and the maintainer. If the maintainer does not react within 72 hours, then you can email the list with the ticket number and request that someone else commit the change.
Okidoki.
Cheers, Eloy
On Jul 13, 2007, at 12:23, Eloy Duran wrote:
As you can see the differences start to occur from: "have_library: checking for SSL_library_init() in -lssl...". Which returns yes for /usr but no for /opt/local. Also it says this in the log for /opt/local: /usr/bin/ld: warning can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/libz.1.dylib referenced from: /opt/local/lib/libcrypto.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)
Uhmmmm..... Is this why it fails to build?? I mean that path can't be correct can it? But that path doesn't really seem to be in there so I don't think that's the cause:
$ strings /opt/local/lib/libcrypto.0.9.8.dylib | grep Developer cc -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -fno-common -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386
Could anybody offer any tips on where I should look??? I'm so close, it's getting frustrating! hahahahaha ;)
The path /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/libz.1.dylib is wrong, to be sure. It should be looking in /opt/local/lib/libz. 1.dylib. I believe I read that it means someone is interpreting the - isysroot parameter incorrectly, but I didn't get to the final solution. But if you search Google for the following two quoted strings you'll see many other instances of the problem. "can't open dynamic library" "/Developer/SDKs" Perhaps one of those threads indicates the solution. http://www.google.com/search?hl=en&q=%22can%27t+open+dynamic+library% 22+%22%2FDeveloper%2FSDKs%22&btnG=Search
As you can see the differences start to occur from: "have_library: checking for SSL_library_init() in -lssl...". Which returns yes for /usr but no for /opt/local. Also it says this in the log for /opt/local: /usr/bin/ld: warning can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/libz.1.dylib referenced from: /opt/local/lib/libcrypto.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)
Uhmmmm..... Is this why it fails to build?? I mean that path can't be correct can it? But that path doesn't really seem to be in there so I don't think that's the cause:
$ strings /opt/local/lib/libcrypto.0.9.8.dylib | grep Developer cc -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -fno-common -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386
Could anybody offer any tips on where I should look??? I'm so close, it's getting frustrating! hahahahaha ;)
The path /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/libz.1.dylib is wrong, to be sure. It should be looking in /opt/local/lib/libz. 1.dylib. I believe I read that it means someone is interpreting the - isysroot parameter incorrectly, but I didn't get to the final solution. But if you search Google for the following two quoted strings you'll see many other instances of the problem.
"can't open dynamic library" "/Developer/SDKs"
Perhaps one of those threads indicates the solution.
http://www.google.com/search?hl=en&q=%22can%27t+open+dynamic+library% 22+%22%2FDeveloper%2FSDKs%22&btnG=Search
I think this one sums it all up: http://lists.apple.com/archives/darwin-dev/2006/Apr/msg00042.html And guess what..... It builds yihaa! So thanks for the pointer. But then this raises the question off how to accomplish this with macports. As in: Should I create a symlink in pre-build like: $ ln -s /opt /Developer/SDKs/MacOSX10.4u.sdk/opt And then remove it in post-build? Or should this be created at installation time of macports? Because like you said, that search yields a lot more than one result.... Cheers, A very happy Eloy
And like I hoped all gems are being build with the config that ruby was build with. So hpricot from macports and libxml from rubygems both build universal extensions :) So all the ports that are rubygems based, should they by default have: "universal_variant no"? Because they will be build in the same manner as ruby was build nonetheless. Eloy On 7/13/07, Eloy Duran <eloy.de.enige@gmail.com> wrote:
As you can see the differences start to occur from: "have_library: checking for SSL_library_init() in -lssl...". Which returns yes for /usr but no for /opt/local. Also it says this in the log for /opt/local: /usr/bin/ld: warning can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/libz.1.dylib referenced from: /opt/local/lib/libcrypto.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)
Uhmmmm..... Is this why it fails to build?? I mean that path can't be correct can it? But that path doesn't really seem to be in there so I don't think that's the cause:
$ strings /opt/local/lib/libcrypto.0.9.8.dylib | grep Developer cc -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -fno-common -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386
Could anybody offer any tips on where I should look??? I'm so close, it's getting frustrating! hahahahaha ;)
The path /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/libz.1.dylib is wrong, to be sure. It should be looking in /opt/local/lib/libz. 1.dylib. I believe I read that it means someone is interpreting the - isysroot parameter incorrectly, but I didn't get to the final solution. But if you search Google for the following two quoted strings you'll see many other instances of the problem.
"can't open dynamic library" "/Developer/SDKs"
Perhaps one of those threads indicates the solution.
http://www.google.com/search?hl=en&q=%22can%27t+open+dynamic+library% 22+%22%2FDeveloper%2FSDKs%22&btnG=Search
I think this one sums it all up: http://lists.apple.com/archives/darwin-dev/2006/Apr/msg00042.html
And guess what..... It builds yihaa! So thanks for the pointer.
But then this raises the question off how to accomplish this with macports. As in:
Should I create a symlink in pre-build like: $ ln -s /opt /Developer/SDKs/MacOSX10.4u.sdk/opt And then remove it in post-build?
Or should this be created at installation time of macports? Because like you said, that search yields a lot more than one result....
Cheers, A very happy Eloy
On Jul 13, 2007, at 17:14, Eloy Duran wrote:
And like I hoped all gems are being build with the config that ruby was build with. So hpricot from macports and libxml from rubygems both build universal extensions :)
So all the ports that are rubygems based, should they by default have: "universal_variant no"? Because they will be build in the same manner as ruby was build nonetheless.
If there is something that needs to be done in all the ruby ports, then it should not be done in all the ruby ports, but instead in the ruby portgroup.
On Jul 13, 2007, at 16:54, Eloy Duran wrote:
The path /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/libz.1.dylib is wrong, to be sure. It should be looking in /opt/local/lib/libz. 1.dylib. I believe I read that it means someone is interpreting the - isysroot parameter incorrectly, but I didn't get to the final solution. But if you search Google for the following two quoted strings you'll see many other instances of the problem.
"can't open dynamic library" "/Developer/SDKs"
Perhaps one of those threads indicates the solution.
http://www.google.com/search?hl=en&q=%22can%27t+open+dynamic+library% 22+%22%2FDeveloper%2FSDKs%22&btnG=Search
I think this one sums it all up: http://lists.apple.com/archives/darwin-dev/2006/Apr/msg00042.html
And guess what..... It builds yihaa! So thanks for the pointer.
But then this raises the question off how to accomplish this with macports. As in:
Should I create a symlink in pre-build like: $ ln -s /opt /Developer/SDKs/MacOSX10.4u.sdk/opt And then remove it in post-build?
Or should this be created at installation time of macports? Because like you said, that search yields a lot more than one result....
MacPorts should not be modifying things outside of /opt, certainly not the contents of a Mac OS X SDK. This is a workaround, not a real solution.
Hello,
Should I create a symlink in pre-build like: $ ln -s /opt /Developer/SDKs/MacOSX10.4u.sdk/opt And then remove it in post-build?
Or should this be created at installation time of macports? Because like you said, that search yields a lot more than one result....
MacPorts should not be modifying things outside of /opt, certainly not the contents of a Mac OS X SDK. This is a workaround, not a real solution.
The solution was rather simple, I had to simply omit the sysroot flag. Ruby uses only dependencies that are build with macports, so the flag isn't necessary anyway. I have now submitted a patch that adds universal support to the ruby port. http://trac.macosforge.org/projects/macports/ticket/12314
And like I hoped all gems are being build with the config that ruby was build with. So hpricot from macports and libxml from rubygems both build universal extensions :)
So all the ports that are rubygems based, should they by default have: "universal_variant no"? Because they will be build in the same manner as ruby was build nonetheless.
If there is something that needs to be done in all the ruby ports, then it should not be done in all the ruby ports, but instead in the ruby portgroup.
Understood, I've submitted a patch which adds "universal_variant no" to all gem based ports. http://trac.macosforge.org/projects/macports/ticket/12317 I have also submitted a patch that adds "universal_variant no" to rb-rubygems. http://trac.macosforge.org/projects/macports/ticket/12318 (I accidentally marked it as a defect instead of an enhancement.) Now the last patch I have is the one for rubycocoa itself. But first I would like to now if it's allowed to change the name of the port? Because the name of the software is rubycocoa not cocoa.... Also I saw today that building from a clean macports installation with the universal variant now breaks at the point where perl is being build (for autoconf?). I must have been sleeping last time I checked (about 2 weeks ago), but I could have sworn it didn't fail back then. But actually more important, perl doesn't build as a universal. So should I tell my users to tell port to build rubycocoa as a universal and expect it to break at the point of perl, then tell port to build perl as a non-universal and afterwards again tell port to build rubycocoa as a universal?? This doesn't really feel ok..... Cheers, Eloy
Totally offtopic but good to say I think: Ryan thanks for all your good and also fast replies and help! Macports totally rocks thanks to people like you :) Of course this counts for all the others on the team too! Eloy On 7/17/07, Eloy Duran <eloy.de.enige@gmail.com> wrote:
Hello,
Should I create a symlink in pre-build like: $ ln -s /opt /Developer/SDKs/MacOSX10.4u.sdk/opt And then remove it in post-build?
Or should this be created at installation time of macports? Because like you said, that search yields a lot more than one result....
MacPorts should not be modifying things outside of /opt, certainly not the contents of a Mac OS X SDK. This is a workaround, not a real solution.
The solution was rather simple, I had to simply omit the sysroot flag. Ruby uses only dependencies that are build with macports, so the flag isn't necessary anyway.
I have now submitted a patch that adds universal support to the ruby port. http://trac.macosforge.org/projects/macports/ticket/12314
And like I hoped all gems are being build with the config that ruby was build with. So hpricot from macports and libxml from rubygems both build universal extensions :)
So all the ports that are rubygems based, should they by default have: "universal_variant no"? Because they will be build in the same manner as ruby was build nonetheless.
If there is something that needs to be done in all the ruby ports, then it should not be done in all the ruby ports, but instead in the ruby portgroup.
Understood, I've submitted a patch which adds "universal_variant no" to all gem based ports. http://trac.macosforge.org/projects/macports/ticket/12317
I have also submitted a patch that adds "universal_variant no" to rb-rubygems. http://trac.macosforge.org/projects/macports/ticket/12318 (I accidentally marked it as a defect instead of an enhancement.)
Now the last patch I have is the one for rubycocoa itself. But first I would like to now if it's allowed to change the name of the port? Because the name of the software is rubycocoa not cocoa....
Also I saw today that building from a clean macports installation with the universal variant now breaks at the point where perl is being build (for autoconf?). I must have been sleeping last time I checked (about 2 weeks ago), but I could have sworn it didn't fail back then. But actually more important, perl doesn't build as a universal. So should I tell my users to tell port to build rubycocoa as a universal and expect it to break at the point of perl, then tell port to build perl as a non-universal and afterwards again tell port to build rubycocoa as a universal?? This doesn't really feel ok.....
Cheers, Eloy
On Jul 17, 2007, at 14:42, Eloy Duran wrote: [snip]
I have now submitted a patch that adds universal support to the ruby port. http://trac.macosforge.org/projects/macports/ticket/12314
[snip]
I've submitted a patch which adds "universal_variant no" to all gem based ports. http://trac.macosforge.org/projects/macports/ticket/12317
I have also submitted a patch that adds "universal_variant no" to rb-rubygems. http://trac.macosforge.org/projects/macports/ticket/12318 (I accidentally marked it as a defect instead of an enhancement.)
I fixed that. Don't forget to add yourself in the Cc line of every bug you submit, and also Cc the port maintainer, if there is one, so that they learn about the ticket's existence.
Now the last patch I have is the one for rubycocoa itself. But first I would like to now if it's allowed to change the name of the port? Because the name of the software is rubycocoa not cocoa....
I think this is still an undefined area. It would be nice if we could just "svn mv rb-cocoa rb-rubycocoa" (if indeed consensus is that this is a good idea) but this would be bad for all users who already have rb-cocoa installed. They would not be informed that their port has been renamed and they would never know if there are any updates unless they later manually install rb-rubycocoa. In some past cases, port authors have kept the portfile under the old name and changed it in some way -- either so that it just outputs an error message advising the user to install the other port, or going so far as to automatically uninstall the old port and installing the new one. The latter seems like a good idea from a user's ease-of-use perspective but the implementation of this feature in those portfiles was deemed scary because MacPorts has no support for this. I think it would be beneficial for MacPorts to have portfile syntax to say that a port has been superseded by a different port. This way all ports like this could be handled identically. We could start with something very simple: a new keyword for portfiles: superseded_by rb-rubycocoa Anyone who tries to install this port gets a message that the port has been replaced by this other one. Anyone who already has the old port installed will see something in "port outdated", and if they try to "port upgrade" the port, they'll get a message advising them to uninstall the current port and install this new port. Then later, if we want, we can look into a process of automatically uninstalling the old port and installing the new one, but we don't need to think about that now.
Also I saw today that building from a clean macports installation with the universal variant now breaks at the point where perl is being build (for autoconf?). I must have been sleeping last time I checked (about 2 weeks ago), but I could have sworn it didn't fail back then. But actually more important, perl doesn't build as a universal. So should I tell my users to tell port to build rubycocoa as a universal and expect it to break at the point of perl, then tell port to build perl as a non-universal and afterwards again tell port to build rubycocoa as a universal?? This doesn't really feel ok.....
I think the simpler instructions for your users would be to install perl5.8 without the +universal variant, then install rubycocoa with the +universal variant. And, why perl again? autoconf requires perl5.8... what requires autoconf? Giving perl5.8 a functional +universal variant can be investigated separately. The port has no maintainer, however.
I fixed that. Don't forget to add yourself in the Cc line of every bug you submit, and also Cc the port maintainer, if there is one, so that they learn about the ticket's existence.
Thanks.
I think this is still an undefined area. It would be nice if we could just "svn mv rb-cocoa rb-rubycocoa" (if indeed consensus is that this is a good idea) but this would be bad for all users who already have rb-cocoa installed. They would not be informed that their port has been renamed and they would never know if there are any updates unless they later manually install rb-rubycocoa.
In some past cases, port authors have kept the portfile under the old name and changed it in some way -- either so that it just outputs an error message advising the user to install the other port, or going so far as to automatically uninstall the old port and installing the new one. The latter seems like a good idea from a user's ease-of-use perspective but the implementation of this feature in those portfiles was deemed scary because MacPorts has no support for this.
I think it would be beneficial for MacPorts to have portfile syntax to say that a port has been superseded by a different port. This way all ports like this could be handled identically. We could start with something very simple: a new keyword for portfiles:
superseded_by rb-rubycocoa
Anyone who tries to install this port gets a message that the port has been replaced by this other one. Anyone who already has the old port installed will see something in "port outdated", and if they try to "port upgrade" the port, they'll get a message advising them to uninstall the current port and install this new port. Then later, if we want, we can look into a process of automatically uninstalling the old port and installing the new one, but we don't need to think about that now.
That looks like a real good idea to me. Who should/will create this patch?
I think the simpler instructions for your users would be to install perl5.8 without the +universal variant, then install rubycocoa with the +universal variant.
I haven't checked it yet, but I thought that this might build dependencies fro ruby as non universal.
And, why perl again? autoconf requires perl5.8... what requires autoconf?
Giving perl5.8 a functional +universal variant can be investigated separately. The port has no maintainer, however.
The ruby portfile uses autoconf, but I'm not sure if it's really needed. I will try this later on... I have added a new patch to http://trac.macosforge.org/projects/macports/ticket/12317 which will now add +universal to the default_variants if the ruby in ${prefix}/bin/ruby is a universal binary. Cheers, Eloy
I think the simpler instructions for your users would be to install perl5.8 without the +universal variant, then install rubycocoa with the +universal variant.
I haven't checked it yet, but I thought that this might build dependencies fro ruby as non universal.
And, why perl again? autoconf requires perl5.8... what requires autoconf?
Giving perl5.8 a functional +universal variant can be investigated separately. The port has no maintainer, however.
The ruby portfile uses autoconf, but I'm not sure if it's really needed. I will try this later on...
I have added a patch which instead of patching configure.in patches configure, so autoconf (and perl) is not needed anymore. I have tested it with a fresh installation and it builds without a problem, but I'm by no means a configure/make expert so if there's some reason why this shouldn't be done I would like to hear it. http://trac.macosforge.org/projects/macports/ticket/12314 Cheers, Eloy
*bump* Hello, Before I can finally submit the RubyCococa portfile patch these tickets still need to be resolved.... http://trac.macosforge.org/projects/macports/ticket/12314 http://trac.macosforge.org/projects/macports/ticket/12317 http://trac.macosforge.org/projects/macports/ticket/12318 Cheers, Eloy On 7/19/07, Eloy Duran <eloy.de.enige@gmail.com> wrote:
I think the simpler instructions for your users would be to install perl5.8 without the +universal variant, then install rubycocoa with the +universal variant.
I haven't checked it yet, but I thought that this might build dependencies fro ruby as non universal.
And, why perl again? autoconf requires perl5.8... what requires autoconf?
Giving perl5.8 a functional +universal variant can be investigated separately. The port has no maintainer, however.
The ruby portfile uses autoconf, but I'm not sure if it's really needed. I will try this later on...
I have added a patch which instead of patching configure.in patches configure, so autoconf (and perl) is not needed anymore. I have tested it with a fresh installation and it builds without a problem, but I'm by no means a configure/make expert so if there's some reason why this shouldn't be done I would like to hear it.
http://trac.macosforge.org/projects/macports/ticket/12314
Cheers, Eloy
participants (2)
-
Eloy Duran
-
Ryan Schmidt