Revision as of 14:01, 4 December 2006

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...