# ref_impl_eiffel Initial post **Category:** [Reference Implementation: Eiffel (archive)](https://discourse.openehr.org/c/reference-implementation-eiffel-archive/161) **Created:** 2006-05-11 03:05 UTC **Views:** 6 **Replies:** 4 **URL:** https://discourse.openehr.org/t/ref-impl-eiffel-initial-post/14535 --- ## Post #1 by @thomas.beale I'm afraid I forgot to subscribe myself to this list until just now \(being the list owner and all;\-\), so I missed the previous posts from Bert\. Bert \- can you resend them \- sorry about that, but at least the threading will be more normal if we do that\. \- thomas --- ## Post #2 by @peter.gummer Quoting Thomas Beale: > \.\.\. I missed the previous posts from Bert\. > Bert \- can you resend them \- sorry about that, but at least the > threading will be more normal if we do that\. Allow me :\-\) This was the first message I saw from Bert: > Hi > > I reported last week, I was missing an Eiffel class which was referenced > from \(a maybe never referenced\) class ADL\_EXPR\_CONSTRAINT > > Now I am missing a referenced class which is inherited from, the child > is C\_DATE\_TIME, the missing parent is ADL\_DEFINITIONS, it is used a > perent at more locations, f\.e\. C\_DURATION > > Maybe it is not important, or maybe I just don't find those classes > > Can someone explain this > > thanks > bert And this was the second message I saw from Bert: --- ## Post #3 by @thomas.beale >   >> Hi >> >> I reported last week, I was missing an Eiffel class which was referenced >> from \(a maybe never referenced\) class ADL\_EXPR\_CONSTRAINT >> >> Now I am missing a referenced class which is inherited from, the child >> is C\_DATE\_TIME, the missing parent is ADL\_DEFINITIONS, it is used a >> perent at more locations, f\.e\. C\_DURATION >> >> Maybe it is not important, or maybe I just don't find those classes >> Bert, which application were you trying to build? >   >> Hi Thomas, I guess you are the one to address for these issues >> >> Just like the java\-sources, I am getting lost in the Eiffel sources\. >> >> First Question, >> there are three branches, I do not understand their purpose >> ADL2 >> dotnet >> java\_adl >> Can you point me to a location where this is explained? The >> project\_page\.htm's look to me the same\. >>     we are not using the branches at the moment \- they were created for specific purposes\. The ADL2 one might go back into action later\. All the current work is on the TRUNK\. >> Second Question, >> >> I compiled the project from TRUNK/libraries/openehr/test/app amd >> discoverd that a file ADL\_DEFINITIONS is missing, I found it somewhere >>     I don't understand that \- ADL\_DEFINITIONS is not used by that application at all\. >> under components, but it made me doubt\. Is that the same file, is it the >> good version, why isn't it in somewhere in a position where a project >> referencing this file can find it? >> >> Third Question >> Is the TRUNK the best tree to follow? >>     this is where all the work is occurring right now\.\.\. >> Fourth Question >> Am I the only one with questions like this, and how does thjat come, do >> you think >> a few things you have asked are to do with being new\(ish\) to Eiffel I suspect, but some are due to only myself current working on the Eiffel project so far \- I wouldn't guarantee that the directory structures are completely perfect yet\. We are just getting into serious software building now, as the specification work becomes less time\-consuming\.\.\.but questions are no problem\. As we find problems, we can fix them quickly\. One problem I would like to fix is the makefiles\. At the moment I used really dumb makefiles because I wasn't able to make microsoft nmake work properly with unix\-style makefiles\. But maybe one of you can show how to do it\.\.\. \- thomas --- ## Post #4 by @peter.gummer Thomas Beale wrote: > One problem I would like to fix is the makefiles\. At the moment I used > really dumb makefiles because I wasn't able to make microsoft nmake work > properly with unix\-style makefiles\. But maybe one of you can show how to > do it\.\.\. I've been experimenting with SCons \(www\.scons\.org\)\. It seems much more flexible and portable than make\. You have to install Python \(www\.python\.org\) to use SCons, but that's painless\. So far, I've figured out how to get it to freeze a hierarchy of Eiffel projects\. Executing this from the top of the source code tree will build all projects in the hierarchy: $ scons If you cd down the tree into a particular project or group of projects, then it will build just that part of the hierarchy: $ scons \-u To achieve this, create a file in each project directory \(the directory containing the Ace file\) called "SConscript", containing these two lines:   Import\('env'\)   env\.Eiffel\('ace'\) Then, at the top of the source hierarchy, create a file called "SConstruct" containing this:   import os   env = Environment\(ENV = os\.environ\)   Export\('env'\)   actions = \[     Delete\('$\{SOURCE\.dir\}/EIFGEN'\),     'ec \-batch \-ace $\{SOURCE\.abspath\} \-project\_path $\{SOURCE\.dir\.abspath\} \-freeze \-c\_compile'   \]   env\.Append\(BUILDERS = \{'Eiffel': Builder\(action = actions, src\_suffix = 'ace'\)\}\)   SConscript\(dirs = \[     'apps/myapp1/app',     'apps/myapp2/app',     'apps/group/pair1/app',     'apps/group/pair2/app'   \]\) This SConstruct file is doing three things: 1\. It's importing your environment so that it knows where to find ec\.exe\. Note that $ISE\_EIFFEL\\studio\\spec\\windows\\bin must be in your path\. 2\. It's teaching SCons how to freeze an Eiffel project\. SCons knows about C, Java, etc\. but we need to teach it about Eiffel :\-\( 3\. It's specifying where to find the SConscript files\. Getting it to finalise the projects rather the freeze them is easy, but I'm new to SCons and I haven't quite figured out the best way to specify that we want a 'final' target rather than a 'workbench' target\. SCons has the concepts of targets and default targets, sort of like make, but different\. \- Peter --- ## Post #5 by @system Thomas Beale schreef: >   >>> Hi >>> >>> I reported last week, I was missing an Eiffel class which was referenced >>> from \(a maybe never referenced\) class ADL\_EXPR\_CONSTRAINT >>> >>> Now I am missing a referenced class which is inherited from, the child >>> is C\_DATE\_TIME, the missing parent is ADL\_DEFINITIONS, it is used a >>> perent at more locations, f\.e\. C\_DURATION >>> >>> Maybe it is not important, or maybe I just don't find those classes >>> > > Bert, which application were you trying to build? >   Please excuse me, I forgot\. I build applications for understanding the sourcecode, see my post in the implementorlist, I understand classes best when I see them in interaction\. And sometimes I read sourcecode, and the EiffelStudio is very handy, but it has a shortcoming\. It is only possible to navigate \(jump\) throught the code if it is compiled\. Classes which are not compiled inside a project, because they are not referenced \(the appear as grey, instead of blue in the Studio\), one cannot navigate through\. But classes which are not referenced in a certatain application, does not mean, these classes are there for no reasons\. maybe when the framework is used in another application, these classes will be compiled\. This is clearily a shortcoming of EiffelStudio, I had many times a problem with that, also when buidling a set of classes, I always had to make a dummy reference to make features of the IDE for that class work\. So I study the Eiffel code, you told me, you used Eiffel as a kind of case\-tool, and I think, it is very suitable for this purpose, though not perfect \(see above, why\), \(but nothing is perfect\)\. Thus, because it is a case\-tool, I read classes which are not referenced, because I cannot judge if they will never be referenced, they exist, don't they\. And then I come to a class which does inherit from a class which does not exist, and that was my question about\. The problem is that I work in the TRUNK, I should work in a TAG which ought to be stable\. The TRUNK does not need to be stable, and things can change\. It is a pity that there is no TAG for Eiffel\. So if you find a question from me from a week ago about a certain Eiffel class, missing in the TRUNK, I learned to live without that knowledge\. I found the class ADL\_DEFINITIONS somewhere else \(in components/adl\_parser/src/interface\)\. >>> Hi Thomas, I guess you are the one to address for these issues >>> >>> Just like the java\-sources, I am getting lost in the Eiffel sources\. >>> >>> First Question, >>> there are three branches, I do not understand their purpose >>> ADL2 >>> dotnet >>> java\_adl >>> Can you point me to a location where this is explained? The >>> project\_page\.htm's look to me the same\. >>>     > > we are not using the branches at the moment \- they were created for > specific purposes\. The ADL2 one might go back into action later\. All the > current work is on the TRUNK\. >   This good to know, it takes away uncertainty\. >>> Second Question, >>> >>> I compiled the project from TRUNK/libraries/openehr/test/app amd >>> discoverd that a file ADL\_DEFINITIONS is missing, I found it somewhere >>>     > > I don't understand that \- ADL\_DEFINITIONS is not used by that > application at all\. >   >>> under components, but it made me doubt\. Is that the same file, is it the >>> good version, why isn't it in somewhere in a position where a project >>> referencing this file can find it? >>> >>> Third Question >>> Is the TRUNK the best tree to follow? >>>     > > this is where all the work is occurring right now\.\.\. >   >>> Fourth Question >>> Am I the only one with questions like this, and how does thjat come, do >>> you think >>> > > a few things you have asked are to do with being new\(ish\) to Eiffel I > suspect, but some are due to only myself current working on the Eiffel > project so far \- I wouldn't guarantee that the directory structures are > completely perfect yet\. We are just getting into serious software > building now, as the specification work becomes less > time\-consuming\.\.\.but questions are no problem\. As we find problems, we > can fix them quickly\. >   That is possible, I am new to Eiffel, but Eiffel is a very easy environment, too bad it is not recognized more\. The first steps are difficult, different then other environments, one does need to read the getting started guide\. Too bad there are not more people reading your Eiffelcode, and are involved at that level\. > One problem I would like to fix is the makefiles\. At the moment I used > really dumb makefiles because I wasn't able to make microsoft nmake work > properly with unix\-style makefiles\. But maybe one of you can show how to > do it\.\.\. >   Why should you want to make makefiles, it is to build applications, but you always said, Eiffel is a case tool, building the application is only something to proof the concept\. In my concept, Eiffel is not too good for building applications, people at Eiffel think so to\. they translate the code to C, and now also to CLI\. There should be more translators to Java, C\#, intelligent translators which handle the multiple inheritance \(perhaps by using interfaces?\) and the invariants , the DbC But they will never come, the Eiffel community is too small I am afraid\. We are stuck on doing this by hand\. \(Ocean does, Acode does\) \(It wouldn't be too hard, perhaps a project for making money, there are examples, there are open source eiffel compilers, one can learn how to build C\-code, so there must be enough knowledge in that to do the same for java and C\# \(only fantasy, life is too short\)\) --- **Canonical:** https://discourse.openehr.org/t/ref-impl-eiffel-initial-post/14535 **Original content:** https://discourse.openehr.org/t/ref-impl-eiffel-initial-post/14535