Installing Rotor on Mac OS X
Introduction:
With the release of the Shared Source CLI version 1.0 (or Rotor, it's code-name), Microsoft has made a first step towards fulfilling the cross-platform potential of the .Net Framework. Now, a shared subset of the .Net Framework is available on Mac OS X, Windows, and FreeBSD. Soon, this will extend to Linux with a full release of the project.
The scope of this tutorial is fairly limited, but it will be followed up with more articles on more advanced projects that can be accomplished with the SSCLI. In this tutorial, we will cover how you can download the SSCLI 1.0 release, install it, and make it easier to use with Mac OS X. We won't cover anything related to setting up the Tk package, although if there is sufficient demand another tutorial can be written to cover that topic.
Requirements:
In order to install Rotor on Mac OS X, you need to fulfill a number of requirements. Most computers capable of running Mac OS X will meet these requirements.
- Mac OS X 10.2.
- Apple Developer Tools.
- Tk package installed if you want to run all the samples.
- 256 MB of memory: 512 MB recommended.
- Ensure the BSD subsystem is installed. (This is the default installation.)
- Stuffit™ Expander 7.0 will unpack the archive. Otherwise use gnutar and not the default tar.
- One gigabyte of free disk space to build the distribution.
Downloading Rotor:
The Rotor 1.0 package is 15 megabytes in size. The documentation associated with it is only a few hundred kilobytes more. I highly recommend downloading both, as the documentation provides a full listing of all of classes included in Rotor. Before we go any farther, you will need to retrieve these files.
The links for downloading both files are near the top of the page, as can be seen in Figure 1.
Figure 1: Rotor Download Page
When you're all finished, you will have two files, sscli_20021101.tgz and sscli_ref_20021101.tgz.
Unpacking Rotor:
This step is, by far, the easiest process in the installation of Rotor. If you have Stuffit Expander 7.0 installed on your system, you can simply double-click each file to unpack them. If not, I would recommend downloading it from the .You also have the option of using the gnutar utility to unpack the files. In order to do this, open up a terminal window, and switch to whatever directory contains the SSCLI archives. If you have not altered your web browser's defaults for this setting, they will be on the desktop. To switch to the desktop, type cd ~/Desktop. Next, type gnutar xzf sscli_20021101.tgz and then, once that's finished, gnutar xzf sscli_ref_20021101.tgz.
Getting ready to build Rotor:
Now that all of the necessary files to build Rotor are available, we can get into the heart of this process. Go back to your terminal window, or open up a new one if you haven't used it yet. Switch into your SSCLI directory, as seen in Figure 2.
Figure 2: Switching to the sscli directory and source'ing your env file
Once you have made it in to the sscli directory take a look at its contents quickly. Next, assuming that you are running tcsh or csh, type in source env.csh as seen at the bottom of Figure 2 (note: if you're not sure what shell you are running, then chances are you are using tcsh. Mac OS X uses tcsh by default). If you're curious as to what the source command does exactly, here is the official write-up on it from the tcsh man file:
source [-h] name [args ...]
The shell reads and executes commands from name.
The commands are not placed on the history list.
If any args are given, they are placed in argv.
(+) source commands may be nested; if they are
nested too deeply the shell may run out of file
descriptors. An error in a source at any level
terminates all nested source commands. With -h,
commands are placed on the history list instead of
being executed, much like `history -L'.
Building Rotor:
Finally, we are ready to compile Rotor from its source code. Before we start, you should be aware that this is a fairly lengthy process. Although I didn't remember to time it when I installed Rotor, I found that it takes over an hour, and less than 8 (I let it compile overnight). My assumption is that takes somewhere between 1.5 and 3 horus to compile, at least on a G4/550MHz with 512MB RAM. Your mileage may vary, depending on CPU speed and available RAM. If you have left the sscli directory with terminal, you will want to go back to it. Once you're in it, just type in ./buildall, and go play for a while. If this seems at all confusing, take a look at Figure 3.
Figure 3: Running buildall on Rotor.
Configuring your environment:
Now that Rotor has been successfully installed on your system, there are a couple more things to do. Next, we need to set up a few aliases to make your life easier. In order to do this, switch back to the root of your home directory by typing cd or cd ~ into a terminal (see Figure 4 for more details). After you have done this, you will need to modify your .cshrc file, or create a new one. This process is straightforward; you can accomplish it with one command regardless of whether or not you already have a .cshrc file. This file contains all of the options with which you wish to apply to your shell when it is loaded. To open up the file, type pico .cshrc at the command prompt (once again, see Figure 4).
Figure 4: Opening a .cshrc file.
Once you have done this, you will be presented with an editor window. Into this window you will want to type in (or copy and paste) the following lines:
alias csc /Users/<;Your User Name>;/Desktop/sscli/build/v1.ppcfstchk.rotor/csc
alias clix /Users/<;Your User Name>;/Desktop/sscli/build/v1.ppcfstchk.rotor/clix
alias jsc clix /Users/<;Your User Name>;/Desktop/sscli/build/v1.ppcfstchk.rotor/jsc.exe
You will have to adjust the paths for each of these aliases to account for differences in your system. If Rotor was built while residing on your Desktop, the only thing you will have to change is your user name. Here, we are creating aliases for the three primary applications that you will be interacting with. csc is the C# compiler, clix is the managed code loader (comparable in some respects to the java or jikes programs included with Java VMs), and jsc is the JScript.Net compiler. An alias acts pretty much like it sounds. It allows you to substitute a short command for a far longer one. This way, instead of having to specify
the full path to csc, clix, or jsc every time you want to use one of them, you can instead just type in csc, clix, or jsc.
Take a look at Figure 5 for more details on this process. Once you are done editing the file, hit control-x, and save the file when prompted with the name .cshrc.
Figure 5: Editing the .cshrc file.
Project Builder:
Since there aren't any dedicated C# IDEs available on Mac OS X yet, besides the rather poor one in Dreamweaver MX (it's a good application, but not for writing source code), you will probably be best off using Project Builder for writing code. There are some idiosyncracies involved in using it, but nothing that could be considered a showstopper. In order to accomplish this, go into the sscli directory with the Finder (in other words, graphically navigate to the sscli directory). Next, go into the samples folder, and then into the hello folder. Once there, you will find a C# source file, an html description, and a few other things. Select the C# file, and then Get Info on it. Under there, go into the "Open with:" option, and change the default application for this file to Project Builder. Once you have done this, click the "Change All..." button in order to make Project Builder the default application for all C# files. See Figure 6 for more details.
Figure 6: Changing the C# default to Project Builder
Hello, Rotor:
Finally, let's run an application. Double-click the Hello.cs file. It will open in Project Builder. Change the Console.WriteLine() call to read "Hello Rotor," instead of "Hello, World." Save the file, and switch to the terminal. Compile the file with the command csc -out:hello hello.cs. After the application has compiled, run it with the command clix hello. If it takes a while to run the application, don't fret. This just happens at times, and should just be ignored. If everything has gone ok, you will see output close to that in Figure 7. Congratulations, you just ran managed code under Mac OS X!
Figure 7: Compiling and running the hello application.
Final Thoughts:
From here, I recommend reading through the Rotor documentation. There's a fair amount of it, and it's all valuable. Run some more samples applications, and just get a feel for what is, and is not available in Rotor. Most of all, have fun!