ActionScript Projects - The Bigger The Better
There’s quite a difference between an IDE you would use for occasional projects and an ‘industrial strength’ one. For example, most Visual Studio Express solutions would consist of one project, I would guess. In contrast, a medium sized solution like Amethyst (that is, our own code, mainly C#) has 18 separate sub-projects with about five or so different configurations (Debug, Release, etc).
Big as t is, the code-base of the Amethyst solution isn’t really quite big enough to justify an automated overnight build system, but if you had 50 or so projects and a million lines of code, then an automated build would probably be essential.
What’s good enough for C# is good enough for ActionScript.
In the next version of Amethyst, we’ll be moving a good deal closer to the ‘industrial strength’ goal. There are two things I’ve done to achieve this. First, I’ve decoupled the MSBuild system from the core IDE. You can now build an Amethyst project file from the command line with MSBuild. Clearly, you would have to set a couple of things like the location of the Adobe compliers which the IDE now sets up, but other than that, it will all work from a batch file. The second thing I’ve done is implemented ‘project reference libraries’.
In Visual Studio, there are two types of reference library you can use. The first is an external library like an assembly over which you have no control (in C#, System.dll, say). The libraries in the current version on Amethyst are like this (e.g. playerglobal.swc). The second type is where the assembly is produced by a sub-project in the solution and is used by another sub-project. In the second case, you want any sub-projects referencing a given project to be rebuilt if you modify the base project. And you also want to be able to specify the build order.
Building the Flex SDK
To see this in action, consider how two projects might use the common ‘frameworks.swc’ library. The first one just loads it from the prebuilt library that is distributed with the Flex SDK. But in the second (below), I’ve built the Flex SDK (using Amethyst) and incorporated it into the solution. I’ve called this Framework.swc (with a capital ’F’) to distinguish it from Adobe’s original framework.swc.
In the screenshot, you can see a Visual Studio solution that consists of a number of projects including, among others, the Amethyst Designer (that’s the Amethyst visual design environment, written in ActionScript) and the Framework library. The Framework library is built from the source code provided with the Flex SDK (and seems to be functionally identical to the original - projects built using the Amethyst compiled Framework.swc work just fine). The AmethystDesigner depends on the Framework library and, below, you can see in the Project Dependencies window that this is the case.
Building the Framework library proved to be a pretty good test of the Amethyst build system – but having built the Framework (and fixed several bugs in the process!), I’m now reasonably happy with AmethystBuild – and as I mentioned above, it now works independently of the main IDE. I’ve used the ’Additional compiler options’ to specify the options needed to build the Framework.swc, though I think I might improve this in a later beta - it’s a bit clunky right now.
But the great advantage of project references is IntelliSense navigation. You can move seamlessly from one project to another - for example, you can use the ’Go to reference’ menu to find, in the Flex framework code, a class that’s referenced in your own project - and once you arrive in the Flex code, you will have full IntelliSense.