ACE to ECF: The Transition Explained

Revision as of 15:23, 5 December 2006 by Manus (Talk | contribs) (Added content for `one configuration for all')

Warning.png Warning: Warning: Article in development, please come back when the warning will be removed

This page address the rationale behind the new ECF configuration format, and clarify what needs got covered by the new system.

Why the change?

As part of the EiffelStudio 5.7 project plan (made in 2005), we finally decided to improve the way one build a project using EiffelStudio. Most of the ideas introduced in 5.7 have originated from discussions we had over the past 6 years with both employees of Eiffel Software and users of EiffelStudio. We actually decided changing this a while ago, but lack of time and various constraints prevented us from doing it until 5.7.

Here are the major points raised by the above discussions:

  • The Project Settings dialog of EiffelStudio 5.6 (and earlier) was not complete, that is to say not all the Lace constructs could be reached from the UI.
  • Lack of clear documentation on the most complex aspect of the Lace specification: mostly class renaming, but also recent additions to Lace for .NET projects.
  • It was hard to have one Ace file for building portable system, usually one needs to have at least three Ace files: one for Windows, one for .NET on Windows and one for UNIX. With the possible addition of Mono on UNIX, it could put this number up to four.
  • When you had C code that depended on the Eiffel Software runtime, you needed again two additional Ace files: one for workbench mode and one for finalized mode.
  • When you had a library that could be compiled in mono- or multithreaded mode, again you would need two Ace files: one for monothreaded and the other one for multithreaded.
  • One could not have both debug and release build of the same project in the same Ace file, again two Ace files are required.
  • The class renaming mechanism was completely not understood and actually difficult to use without asking Eiffel Software how it worked.
  • The addition of .NET components increased the class name clashing dramatically requiring a robust class name clash resolution mechanism.
  • Recursive clusters were actually actually transformed into actual clusters, making it sometime hard to apply some of the Lace construct specification involving clusters, since cluster names had to be guessed by the end-user.
  • Override clusters were simply a hack over normal clusters preventing users from seeing which classes they were actually overriding.
  • Support for ECMA type mapping needed to make INTEGER be INTEGER_32, NATURAL be NATURAL_32, etc...
  • Even if Lace was a public format (specified in ETL2), the Eiffel Software's implementation was quite different and there was no library available to parse it.
  • It is not easy to move a library location since the use of relative path is not properly working (EiffelStudio uses as reference directory the directory where the EIFGEN was located, not the one where the Ace was located)

.

What's new?

One configuration for all

As pointed above, one of the major problem with Lace was the multiplication of Ace files for various platforms/modes/builds of compilation. To address this issue, almost every elements of a configuration file can be conditioned. That is to say you could say that an external declaration is only valid for windows, and another one for UNIX. When the compiler sees the two external declarations, it only chooses the one matching the current platform. If you need to perform a cross-platform compilation, you can manually set the required platform, and the compiler will chose the set platform rather than the current platform.

The builtin conditions are:

  • Platforms: Windows, UNIX, vxWorks, Macintosh
  • .NET: True, False
  • .NET version: a range can be specified
  • Build: Workbench, Finalize
  • Runtime: Static, Dynamic
  • Thread: Multithreaded, Monothreaded
  • Compiler version: a range can be specified

In addition, you can create your own variables and the condition can either be equality or inequality to your variable value.

Library approach

Class name clashing resolution

Why the syntax change?

Because we wanted to make most modification through the UI or through the configuration library, we could have used an object binary format, but we did not chose this approach since it makes configuration versioning in CMS tool completely useless since one cannot visually see the differences.

So we were left with:

  1. Modifying lace
  2. Adopting a new syntax
  3. Using the quite common XML syntax

At the end, we chose XML for the following reasons:

  • We wanted new Eiffel users to easily create their own configuration. XML is very good at that since XML aware text editor are able to provide code completion when we provide a schema, which we do. With Lace, not being self-describing, it is harder for someone completely new to Eiffel to feel what possibilities are offered to him.
  • Anyone could parse XML no need for a special parser
  • The node ordering in XML matches nicely with the layout of an Eiffel system, that is to say, you have libraries, within libraries, you have clusters, within clusters you have either classes or clusters.
  • Schema evolution: with a XSL transform, it is easy to automate conversion from successive revisions of the XML file without building complex tool.
  • There were some semantics changes we added in the new configuration approach that would have required an upgrade from the old Lace format to the new one. So no matter the chosen syntax, a migration was necessary. And because XML offered more than Lace for processing, this was one more reason for choosing XML.
  • XML was already used by other tools addressing some of the shortcomings of Lace.

Summary

If you were to remember a few things about ECF, they should be:

  • One configuration for all platforms (.NET, Windows, UNIX, Mac OS X), all modes (multithreaded/monothreaded, ...), all builds (debug/release, ...) of compilation for your system.
  • Easy to create libraries that only list the required dependencies (it makes the configuration simpler and smaller)
  • Pre and post compilation tasks.