Revision as of 17:49, 5 December 2006

This page address the rationale behind the new ECF configuration format, and clarify which needs were 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

One new element of Ecf is the ability to use another ecf file that we call a library. With Ace files, this was achieved by copy/pasting a master Ace file. Needless to say that it made the work of library author very difficult since they were limited in their refactoring by keeping classes where they were as otherwise every user of the library would have to change his/her Ace files using it. The copy/paste operation was needed for clusters, but also for C compilations options which often changed depending on the platform.

A library is for the end user a black box which exposes a set of classes defined in the library. There is no need to know how the library is implemented, nor is there a need to know at the programming point of view which other library it may reference internally (a part of course, from a management point of view you need to know the dependence since otherwise the library may not compile on your system if you do not have the referenced libraries). For .NET users, you can see it as a .NET Assembly except that this is presented in a source component rather than in a binary component.

Class name clashing resolution

We are not going to explain how the Lace solution worked since very few people understood it. The solution adopted by the new configuration mechanism is based on information hiding, renaming and libraries.

Information Hiding

As mentioned in the library approach section, a library is a black box that only exposes classes written in the library, that is to say all classes from the other libraries used by this library are not externally visible. This is a very efficient way to get rid of roughly 90% of common cases of name clashes. For example, let's consider the following 3 libraries:

Because library c only directly depends on library a, it can only access classes from library a (i.e. only A in this example). The class from library b are not exposed to c. This is how we can solve potential class name clashes coming from library b.

If library c wants to use classes from library b, it needs to explicitly reference library b:

And in this case, library c has access to both A and B.

Renaming

Now we need to tackle the ten remaining percents. For that purpose we use the same mechanism used in Eiffel for solving feature name clashes with multiple inheritance, that is to say class name renaming. Let's take for example the following diagram representing 3 libraries:

Both libraries a and b define a class A. Library c who uses both a and b needs a clear way to distinguish A from a and A from b. We do this by renaming A from b into A_FROM_B. Now when you encounter A in classes of c it means the version from a, when you encounter A_FROM_B the version from b. In other words, the list of classes available to c are:

• A
• A_FROM_B

The good news is that the renaming has a local scope, that is to say it is only valid in the context of library c. Another library used by c that may use either a or b will not be affected by the renaming, making this solution highly scalable for large systems composed of many libraries.

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.
• Only approach guaranteeing a complete solution to class name clash, all other approaches simply post-pone the problem one step further.