Menu
▾
▴
rubycocoa-talk
|
From: Eloy D. <elo...@gm...> - 2007-06-25 11:33:02
|
Hey guys, My English summary/translation is available at: http://www.superalloy.nl/blog/2007/06/25/rubycocoa-source-layout-spring-cleaning-now-is-the-time-for-feedback Cheers, Eloy On 6/25/07, FUJIMOTO Hisa <hi...@fo...> wrote: > Hi the committers > > This week I'll do some important work for the source tree and > build/packaging process. So, sorry to please be less commit your code > the repository, if it's not important. > > Currently, Eloy may be able to explain about my idea/thinking about it > by English, because he made good effort to read my blog and the ML in > japanese (my native lang) about it last week, and I discussed about it > with him. > > Well, Current RubyCocoa has complex dependency of several parts > especially the build and packaging process. The cause of it may be > that the project was started as just extension library as historical > reason, before version 0.4. Now I strongly thought that now is the > time to reconstruct the source tree for make lots of things more > simple. Current RubyCocoa is constructed by the following > moudles/components in fact: > > runtime (or core, it's like JRE in Java maybe): > core/framework # RubyCocoa.framework as shared library > core/extlib # ruby libraries for the ruby command > core/tests # testing for the framework depend on extlib > # for a developer of RubyCocoa itself > > external (runtime depends on): > external/bridgesupport > external/libffi > > devel (for a developer *using* RubyCocoa): > devel/xcode-templates > devel/examples > > tools (for a developer *using* RubyCocoa maybe): > tools/standalonify > tools/rb_nibtool > tools/gen_bridge_doc > tools/rubycocoa > > # this tree is current idea, it's very mutable at now. > > Tools may be embed the framework at the packaging phase rather than > build process. I guess it's better for orthogonality. > > the point; boost up the orthogonality of each module/component for > build and packaging process. I'm going to start reconstructing soon on > the branches/rubycocoa-reconstruct-20070625 on the repository. > > Maybe I can't reply enough, because The wrting, especially by > English, may decrease down sometimes my concentration. sorry ;) > > thanks > -- > hisa > > _______________________________________________ > Rubycocoa-devel mailing list > Rub...@li... > http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel > |
|
From: Laurent S. <lsa...@ap...> - 2007-06-25 20:12:48
|
Thanks for the translation Eloy :-) Hisa-san, this is a great idea. However I really wonder if it will be interesting to ship RubyCocoa as a gem (or multiple gems). RubyCocoa is a too specialized project to be installed by RubyGems. It's Mac OS X specific, and depends on some projects that are currently in misc (like bridgesupport and libffi). It is not possible to package libffi and bridgesupport as gems, because libffi is statically linked to RubyCocoa (it's a .a file) and the bridge support files are now installed inside RubyCocoa.framework (so they need to be available during RubyCocoa.framework build time). Also, gems are good for Ruby libraries and command line utilities, but not OSX frameworks (like RubyCocoa.framework). What will the re-organization do except the idea of shipping RubyCocoa as gem(s)? Laurent On Jun 25, 2007, at 1:32 PM, Eloy Duran wrote: > Hey guys, > > My English summary/translation is available at: > http://www.superalloy.nl/blog/2007/06/25/rubycocoa-source-layout-spring-cleaning-now-is-the-time-for-feedback > > Cheers, > Eloy > > On 6/25/07, FUJIMOTO Hisa <hi...@fo...> wrote: >> Hi the committers >> >> This week I'll do some important work for the source tree and >> build/packaging process. So, sorry to please be less commit your code >> the repository, if it's not important. >> >> Currently, Eloy may be able to explain about my idea/thinking about >> it >> by English, because he made good effort to read my blog and the ML in >> japanese (my native lang) about it last week, and I discussed about >> it >> with him. >> >> Well, Current RubyCocoa has complex dependency of several parts >> especially the build and packaging process. The cause of it may be >> that the project was started as just extension library as historical >> reason, before version 0.4. Now I strongly thought that now is the >> time to reconstruct the source tree for make lots of things more >> simple. Current RubyCocoa is constructed by the following >> moudles/components in fact: >> >> runtime (or core, it's like JRE in Java maybe): >> core/framework # RubyCocoa.framework as shared library >> core/extlib # ruby libraries for the ruby command >> core/tests # testing for the framework depend on extlib >> # for a developer of RubyCocoa itself >> >> external (runtime depends on): >> external/bridgesupport >> external/libffi >> >> devel (for a developer *using* RubyCocoa): >> devel/xcode-templates >> devel/examples >> >> tools (for a developer *using* RubyCocoa maybe): >> tools/standalonify >> tools/rb_nibtool >> tools/gen_bridge_doc >> tools/rubycocoa >> >> # this tree is current idea, it's very mutable at now. >> >> Tools may be embed the framework at the packaging phase rather than >> build process. I guess it's better for orthogonality. >> >> the point; boost up the orthogonality of each module/component for >> build and packaging process. I'm going to start reconstructing soon >> on >> the branches/rubycocoa-reconstruct-20070625 on the repository. >> >> Maybe I can't reply enough, because The wrting, especially by >> English, may decrease down sometimes my concentration. sorry ;) >> >> thanks >> -- >> hisa >> >> _______________________________________________ >> Rubycocoa-devel mailing list >> Rub...@li... >> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
|
From: Fujimoto H. <hi...@fo...> - 2007-06-25 23:31:23
|
Hi guys The *most important point* in the reconstructing is boost up the *orthogonality* on the *build/packaging process*, to make *less dependency*. rubygems is just secondary product. it's one of possibility after the reconstructing. it may be one of many way for distribution. hisa On 6/26/07, Laurent Sansonetti <lsa...@ap...> wrote: > Thanks for the translation Eloy :-) > > Hisa-san, this is a great idea. However I really wonder if it will be > interesting to ship RubyCocoa as a gem (or multiple gems). > > RubyCocoa is a too specialized project to be installed by RubyGems. > It's Mac OS X specific, and depends on some projects that are > currently in misc (like bridgesupport and libffi). It is not possible > to package libffi and bridgesupport as gems, because libffi is > statically linked to RubyCocoa (it's a .a file) and the bridge support > files are now installed inside RubyCocoa.framework (so they need to be > available during RubyCocoa.framework build time). > > Also, gems are good for Ruby libraries and command line utilities, but > not OSX frameworks (like RubyCocoa.framework). > > What will the re-organization do except the idea of shipping RubyCocoa > as gem(s)? > > Laurent > > On Jun 25, 2007, at 1:32 PM, Eloy Duran wrote: > > > Hey guys, > > > > My English summary/translation is available at: > > http://www.superalloy.nl/blog/2007/06/25/rubycocoa-source-layout-spring-cleaning-now-is-the-time-for-feedback > > > > Cheers, > > Eloy > > > > On 6/25/07, FUJIMOTO Hisa <hi...@fo...> wrote: > >> Hi the committers > >> > >> This week I'll do some important work for the source tree and > >> build/packaging process. So, sorry to please be less commit your code > >> the repository, if it's not important. > >> > >> Currently, Eloy may be able to explain about my idea/thinking about > >> it > >> by English, because he made good effort to read my blog and the ML in > >> japanese (my native lang) about it last week, and I discussed about > >> it > >> with him. > >> > >> Well, Current RubyCocoa has complex dependency of several parts > >> especially the build and packaging process. The cause of it may be > >> that the project was started as just extension library as historical > >> reason, before version 0.4. Now I strongly thought that now is the > >> time to reconstruct the source tree for make lots of things more > >> simple. Current RubyCocoa is constructed by the following > >> moudles/components in fact: > >> > >> runtime (or core, it's like JRE in Java maybe): > >> core/framework # RubyCocoa.framework as shared library > >> core/extlib # ruby libraries for the ruby command > >> core/tests # testing for the framework depend on extlib > >> # for a developer of RubyCocoa itself > >> > >> external (runtime depends on): > >> external/bridgesupport > >> external/libffi > >> > >> devel (for a developer *using* RubyCocoa): > >> devel/xcode-templates > >> devel/examples > >> > >> tools (for a developer *using* RubyCocoa maybe): > >> tools/standalonify > >> tools/rb_nibtool > >> tools/gen_bridge_doc > >> tools/rubycocoa > >> > >> # this tree is current idea, it's very mutable at now. > >> > >> Tools may be embed the framework at the packaging phase rather than > >> build process. I guess it's better for orthogonality. > >> > >> the point; boost up the orthogonality of each module/component for > >> build and packaging process. I'm going to start reconstructing soon > >> on > >> the branches/rubycocoa-reconstruct-20070625 on the repository. > >> > >> Maybe I can't reply enough, because The wrting, especially by > >> English, may decrease down sometimes my concentration. sorry ;) > >> > >> thanks > >> -- > >> hisa > >> > >> _______________________________________________ > >> Rubycocoa-devel mailing list > >> Rub...@li... > >> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel > >> > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Rubycocoa-talk mailing list > > Rub...@li... > > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > -- hisa |
|
From: Eloy D. <elo...@gm...> - 2007-06-25 20:23:14
|
Hey Laurent, I just wanted to stress that Hisa's mentioning of packiging as gems is only a possibility absolutely not the reasoning of his idea to restructure the source layout. What his issue is, is that things are getting too intertwined at the moment. So tests were failing that where caused by tools not necessary for the bridge itself. Eg: rubycocoa. So actually it's just about some cleaning of the sourcetree and putting parts, that have outgrown the place where they started, into their own logical place. So I guess that's the gist of it..... :) Eloy On 6/25/07, Laurent Sansonetti <lsa...@ap...> wrote: > Thanks for the translation Eloy :-) > > Hisa-san, this is a great idea. However I really wonder if it will be > interesting to ship RubyCocoa as a gem (or multiple gems). > > RubyCocoa is a too specialized project to be installed by RubyGems. > It's Mac OS X specific, and depends on some projects that are > currently in misc (like bridgesupport and libffi). It is not possible > to package libffi and bridgesupport as gems, because libffi is > statically linked to RubyCocoa (it's a .a file) and the bridge support > files are now installed inside RubyCocoa.framework (so they need to be > available during RubyCocoa.framework build time). > > Also, gems are good for Ruby libraries and command line utilities, but > not OSX frameworks (like RubyCocoa.framework). > > What will the re-organization do except the idea of shipping RubyCocoa > as gem(s)? > > Laurent > > On Jun 25, 2007, at 1:32 PM, Eloy Duran wrote: > > > Hey guys, > > > > My English summary/translation is available at: > > http://www.superalloy.nl/blog/2007/06/25/rubycocoa-source-layout-spring-cleaning-now-is-the-time-for-feedback > > > > Cheers, > > Eloy > > > > On 6/25/07, FUJIMOTO Hisa <hi...@fo...> wrote: > >> Hi the committers > >> > >> This week I'll do some important work for the source tree and > >> build/packaging process. So, sorry to please be less commit your code > >> the repository, if it's not important. > >> > >> Currently, Eloy may be able to explain about my idea/thinking about > >> it > >> by English, because he made good effort to read my blog and the ML in > >> japanese (my native lang) about it last week, and I discussed about > >> it > >> with him. > >> > >> Well, Current RubyCocoa has complex dependency of several parts > >> especially the build and packaging process. The cause of it may be > >> that the project was started as just extension library as historical > >> reason, before version 0.4. Now I strongly thought that now is the > >> time to reconstruct the source tree for make lots of things more > >> simple. Current RubyCocoa is constructed by the following > >> moudles/components in fact: > >> > >> runtime (or core, it's like JRE in Java maybe): > >> core/framework # RubyCocoa.framework as shared library > >> core/extlib # ruby libraries for the ruby command > >> core/tests # testing for the framework depend on extlib > >> # for a developer of RubyCocoa itself > >> > >> external (runtime depends on): > >> external/bridgesupport > >> external/libffi > >> > >> devel (for a developer *using* RubyCocoa): > >> devel/xcode-templates > >> devel/examples > >> > >> tools (for a developer *using* RubyCocoa maybe): > >> tools/standalonify > >> tools/rb_nibtool > >> tools/gen_bridge_doc > >> tools/rubycocoa > >> > >> # this tree is current idea, it's very mutable at now. > >> > >> Tools may be embed the framework at the packaging phase rather than > >> build process. I guess it's better for orthogonality. > >> > >> the point; boost up the orthogonality of each module/component for > >> build and packaging process. I'm going to start reconstructing soon > >> on > >> the branches/rubycocoa-reconstruct-20070625 on the repository. > >> > >> Maybe I can't reply enough, because The wrting, especially by > >> English, may decrease down sometimes my concentration. sorry ;) > >> > >> thanks > >> -- > >> hisa > >> > >> _______________________________________________ > >> Rubycocoa-devel mailing list > >> Rub...@li... > >> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel > >> > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Rubycocoa-talk mailing list > > Rub...@li... > > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > |
|
From: Fujimoto H. <hi...@fo...> - 2007-06-25 23:38:45
|
Thanks Eloy, You are explaining what I want to say better than I :) # this thread should discuss on rubycocoa-devel rather than rubyocoa-talk. hisa On 6/26/07, Eloy Duran <elo...@gm...> wrote: > Hey Laurent, > > I just wanted to stress that Hisa's mentioning of packiging as gems is > only a possibility absolutely not the reasoning of his idea to > restructure the source layout. > What his issue is, is that things are getting too intertwined at the > moment. So tests were failing that where caused by tools not necessary > for the bridge itself. Eg: rubycocoa. So actually it's just about some > cleaning of the sourcetree and putting parts, that have outgrown the > place where they started, into their own logical place. > > So I guess that's the gist of it..... :) > > Eloy > > On 6/25/07, Laurent Sansonetti <lsa...@ap...> wrote: > > Thanks for the translation Eloy :-) > > > > Hisa-san, this is a great idea. However I really wonder if it will be > > interesting to ship RubyCocoa as a gem (or multiple gems). > > > > RubyCocoa is a too specialized project to be installed by RubyGems. > > It's Mac OS X specific, and depends on some projects that are > > currently in misc (like bridgesupport and libffi). It is not possible > > to package libffi and bridgesupport as gems, because libffi is > > statically linked to RubyCocoa (it's a .a file) and the bridge support > > files are now installed inside RubyCocoa.framework (so they need to be > > available during RubyCocoa.framework build time). > > > > Also, gems are good for Ruby libraries and command line utilities, but > > not OSX frameworks (like RubyCocoa.framework). > > > > What will the re-organization do except the idea of shipping RubyCocoa > > as gem(s)? > > > > Laurent > > > > On Jun 25, 2007, at 1:32 PM, Eloy Duran wrote: > > > > > Hey guys, > > > > > > My English summary/translation is available at: > > > http://www.superalloy.nl/blog/2007/06/25/rubycocoa-source-layout-spring-cleaning-now-is-the-time-for-feedback > > > > > > Cheers, > > > Eloy > > > > > > On 6/25/07, FUJIMOTO Hisa <hi...@fo...> wrote: > > >> Hi the committers > > >> > > >> This week I'll do some important work for the source tree and > > >> build/packaging process. So, sorry to please be less commit your code > > >> the repository, if it's not important. > > >> > > >> Currently, Eloy may be able to explain about my idea/thinking about > > >> it > > >> by English, because he made good effort to read my blog and the ML in > > >> japanese (my native lang) about it last week, and I discussed about > > >> it > > >> with him. > > >> > > >> Well, Current RubyCocoa has complex dependency of several parts > > >> especially the build and packaging process. The cause of it may be > > >> that the project was started as just extension library as historical > > >> reason, before version 0.4. Now I strongly thought that now is the > > >> time to reconstruct the source tree for make lots of things more > > >> simple. Current RubyCocoa is constructed by the following > > >> moudles/components in fact: > > >> > > >> runtime (or core, it's like JRE in Java maybe): > > >> core/framework # RubyCocoa.framework as shared library > > >> core/extlib # ruby libraries for the ruby command > > >> core/tests # testing for the framework depend on extlib > > >> # for a developer of RubyCocoa itself > > >> > > >> external (runtime depends on): > > >> external/bridgesupport > > >> external/libffi > > >> > > >> devel (for a developer *using* RubyCocoa): > > >> devel/xcode-templates > > >> devel/examples > > >> > > >> tools (for a developer *using* RubyCocoa maybe): > > >> tools/standalonify > > >> tools/rb_nibtool > > >> tools/gen_bridge_doc > > >> tools/rubycocoa > > >> > > >> # this tree is current idea, it's very mutable at now. > > >> > > >> Tools may be embed the framework at the packaging phase rather than > > >> build process. I guess it's better for orthogonality. > > >> > > >> the point; boost up the orthogonality of each module/component for > > >> build and packaging process. I'm going to start reconstructing soon > > >> on > > >> the branches/rubycocoa-reconstruct-20070625 on the repository. > > >> > > >> Maybe I can't reply enough, because The wrting, especially by > > >> English, may decrease down sometimes my concentration. sorry ;) > > >> > > >> thanks > > >> -- > > >> hisa > > >> > > >> _______________________________________________ > > >> Rubycocoa-devel mailing list > > >> Rub...@li... > > >> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel > > >> > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by DB2 Express > > > Download DB2 Express C - the FREE version of DB2 express and take > > > control of your XML. No limits. Just data. Click to get it now. > > > http://sourceforge.net/powerbar/db2/ > > > _______________________________________________ > > > Rubycocoa-talk mailing list > > > Rub...@li... > > > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Rubycocoa-talk mailing list > > Rub...@li... > > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > -- hisa |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X