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 |