Stephen Steiner
2004-Aug-16 22:08 UTC
[Rubyinstaller-devel] Re: FXRuby and the (new) Ruby Installer for OS X
> Most of the packages we want to include, though, can be built on OS X > without fink or darwinports. I just build all my stuff (ruby, etc) > directly > with apple''s toolchain.Yes, they can.>> Unfortunately I''m going to have to write some stuff (in Ruby, of >> course) to get >> my approach to work since I can''t find a tool that does what I want. > > It would be cool for you to elaborate on your tools ideas here.I''m thinking of installing everything to a virgin OS X install, then building the package directory structure to match the diff of my result and a fresh OS X install. That way every file gets included no matter where it lands.> Typically with OS X the problems fall along major version boundaries > (10.x) > and not along the minor ones. That is, unless you make assumptions of > libraries that are in a later version being in an earlier version (like > readline, etc).I''m more concerned with ./configure ''making assumptions'' based on what I have on my system. Unfortunately, there''s no way to really automate building on different versions of OS X; you have to manually restart the system although that might not be entirely true, now that I think about it. There must be a way to set the boot partition programatically but it''s still a pain.>> 2> This is really the only potential hangup. I''m running OS X 10.3.5 >> and, if I were to >> configure/make on my system, there''s a chance that the result wouldn''t >> run on an earlier version. > > Apple may be able to help us here, or I could just invest in a few more > firewire drives and install the old versions for testing. Truly > though, you > most need to support the current major release (currently Panther) and > the > prior major release (currently Jaguar) with testing on the next release > (Tiger).How could Apple help? Yes, most important is current and future.>> I can make images for a couple of OS X versions but things quickly >> escalate and, >> due to the the sheer number of possible permutations, quickly becomes >> unmanageable. > > This may be a big issue when it comes to extension that you want to > include > in a one-click installer. If you limit those extensions to a bare few > with > a RubyGems graphical installer for other extensions (maybe built on > RubyCocoa) then we could offer gems that are platform specific binaries > (jaguar, panther, tiger, etc).I''m feeling a maintenance headache coming on... The more levels of indirection we throw in here the worse things are going to get.>> Also, testing each installation/OS Version is time consuming. > > It is, one good thing to do would be to build a test suite that > minimally > tests all the bundled packages for operational use...unit tests, etc, > that > would cross these installers.Another huge task and enormously time-consuming (or CPU consuming, at least) step before a release.>> I''m probably being overly paranoid here but I really wouldn''t like to >> give users a >> bad impression of Ruby by having an incompatibility between OS X >> versions >> look like a Ruby problem. > > Possibility, but worse would be that they never got a chance to use > Ruby at > all ;-)Ruby''s already installed on the system (1.6.8). We _could_ just install stuff to work with that release although that does limit us somewhat.>> I''ve noticed that many of the binary distributions have specific >> downloads for specific >> OS X versions (Tcl/Tk Aqua has separate versions for 10.1, 10.2, and >> 10.3 to use >> your example). > > Right...those are the major versions...I think I may just end up building the Panther version and let''s see who cares about other versions. I''m planning on making the build process fully automatic so it should be no big deal to just run it on another OS version.>> I would like to clear up a misperception: OS X ships with the >> developer >> tools. There is no need to download the developer tools unless the >> version of OS X is >> so old (10.1 from the beginning of 2001) that Ruby itself won''t build >> properly with the >> included tools. > > They do, but I cannot imagine someone who is not a developer actually > having > to install the developer toolchain. Oh, and the disks that ship are > current > with the OS first released, but subsequent releases update the > developer > toolchain and that is only available online, not through apple''s > software > update system.Ah, yes. I forgot about the lack of Software Update support. Good point.>>> We should probably add RubyCocoa to the list of included >>> extensions. >> >> Ok! RubyCocoa, BTW, will be darn close to useless without the >> developer tools. > > For the developer, that is true. But if as a developer you created a > RubyCocoa app that you just wanted to deliver, and that app could > require > the install of the one-click OS X for operation, then is would have > high > value.Good point, too.> Additionally, although without the toolchain you cannot build NIB > files for serialized Uis, you can use RubyCocoa to access AppleScript, > Apple > Events, and manually build Uis without NIBs.Yuck! I get your point, however.>> I have come up with a pretty good way to do the installler package and >> I''m researching >> fink and DarwinPorts to see if any of their tools might be helpful. > > Just please don''t make yourself dependent on them from a ''runtime'' > perspective.What do you mean by that?>> I''ll be very interested to hear RIch''s thoughts on this.And, I was right, I was! Steve
Curt Hibbs
2004-Aug-16 22:52 UTC
[Rubyinstaller-devel] Re: FXRuby and the (new) Ruby Installer forOS X
Stephen Steiner wrote:> > Richard Kilmer wrote: > >> I can make images for a couple of OS X versions but things quickly > >> escalate and, > >> due to the the sheer number of possible permutations, quickly becomes > >> unmanageable. > > > > This may be a big issue when it comes to extension that you want to > > include > > in a one-click installer. If you limit those extensions to a bare few > > with > > a RubyGems graphical installer for other extensions (maybe built on > > RubyCocoa) then we could offer gems that are platform specific binaries > > (jaguar, panther, tiger, etc). > > I''m feeling a maintenance headache coming on... The more levels of > indirection > we throw in here the worse things are going to get.Actually this *is* the long-term strategy that I want to pursue. And it really should make things simpler, not more complicated. The idea is to keep the included extensions in the one-click installer to a minimum, but one of the things that is included is RubyGems and the GUI RubyGems Browser (which doesn''t exist yet). At the end of the normal installation, we would pop-up the RubyGems browser to allow the user to install additional packages. Well, that actually might be too overwhelming for a new Ruby users. What I''d really like to do is to create some common groups of packages for specific types of development tasks (like "web development", "database app development", or "text processing") that would install a predefined set of gems, with an option to go to the full gems browser to select individual gems. In any case, the RubyGems browser would, of course, still be available long after the initial installation to allow the user to add more ruby extensions as needed. At some point I''m sure the gems browser will support update notification, where the user can asked to be notified when new versions of his favorite gems are released. There are many reasons why this is a good approach. But the immediate, and most obvious, one is that everyone has the particular favorite extensions that they want to see included in the one-click installer, but its impossible to accommodate all but the most popular requests. With RubyGems we have a much better shot at satisfying everyone''s needs. Curt