murphy@eric.mpr.ca (Gail Murphy) (08/12/89)
This newsgroup seems to be quiet at present, so let's see if anyone else is interested in discussing the automatic configuration management provided by Eiffel. I have found that "es" is great for small Eiffel systems, but once a system starts to become large, the time spent in reanalyzing the system for small bug fixes (ie. forget to define an integer, misspell variable name, only require re-link due to change in external C object) is not acceptable. I have tried to use "ec" in some of these cases, but have found that it is more trouble than it is worth (ie. end up with strange recompilation sequences occurring, etc.). I have done some work in using Eiffel in conjunction with Yacc and Lex and find it particularly slow for es to reanalyze a system when only the Yacc and Lex code have changed, and thus only a re-link is required. Has there been any though to providing an option on es that would output some type of make file (this could be encoded to prevent changes). If changes which the user though would not affect the order of compilation or what needs to be compiled were made, es could then be run from this make file. This would speed up recompilations from simple errors found in later passes and for re-linking. Of course, the user would have to be knowledgable and understand that the resultant system might not run correctly. Any thoughts? Gail Murphy | murphy@joplin.mpr.ca Microtel Pacific Research | joplin.mpr.ca!murphy@uunet.uu.net 8999 Nelson Way, Burnaby, BC | murphy%joplin.mpr.ca@relay.ubc.ca Canada, V5A 4B5, (604) 293-5462 | ...!ubc-vision!joplinmpr.ca!murphy
yost@esquire.UUCP (David A. Yost) (08/14/89)
In article <1752@eric.mpr.ca> murphy@eric.mpr.ca (Gail Murphy) writes: >I have found that "es" is great for small Eiffel systems, but once >a system starts to become large, the time spent in reanalyzing >the system for small bug fixes (ie. forget to define an integer, misspell >variable name, only require re-link due to change in external C object) >is not acceptable. Are you saying that every time you run es it reads all the program text of all the classes in the program to determine what to do? Or is it that there is no way to tell es how the classes depend on external C code? --dave yost
murphy@joplin.mpr.ca (Gail Murphy) (08/18/89)
In article <1352@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: >In article <1752@eric.mpr.ca> murphy@eric.mpr.ca (Gail Murphy) writes: >>I have found that "es" is great for small Eiffel systems, but once >>a system starts to become large, the time spent in reanalyzing >>the system for small bug fixes (ie. forget to define an integer, misspell >>variable name, only require re-link due to change in external C object) >>is not acceptable. > >Are you saying that every time you run es >it reads all the program text of all the >classes in the program to determine what >to do? Or is it that there is no way to >tell es how the classes depend on external >C code? > > --dave yost The external C code that an Eiffel system depends on is described in the Eiffel System Definition File (SDF). I'm not sure exactly how the Eiffel Configuration Management works, but I assume it is something as follows: The root object file is scanned for all inherited and client objects. This list of dependent and inherited objects is used to check dependency times between files to drive the re-compilation sequence. I don't know how much information about the dependency graph between objects is stored in an object's .E files. Maybe someone from ISE can clarify this and correct me if I am off base about any of this. Has anyone had similar experiences with the config system? Gail Murphy | murphy@joplin.mpr.ca Microtel Pacific Research | joplin.mpr.ca!murphy@uunet.uu.net 8999 Nelson Way, Burnaby, BC | murphy%joplin.mpr.ca@relay.ubc.ca Canada, V5A 4B5, (604) 293-5462 | ...!ubc-vision!joplinmpr.ca!murphy
bertrand@eiffel.UUCP (Bertrand Meyer) (08/18/89)
>> Are you saying that every time you run es it reads all the >> program text of all the classes in the program to determine >> what to do? Or is it that there is no way to tell es how >> the classes depend on external C code? >> -- Dave Yost > (...) Maybe someone from ISE can clarify this. > -- Gail Murphy The dependency information is stored in auxiliary files. The compiler (es) uses these files, not the source text, to determine what needs to be recompiled. For external files, the only time involved is linking time. A scheme for incremental linking has been devised but is not part of 2.2. -- Bertrand Meyer