ProposalProjectFiles - Revision history

Manus: /* Specification */

2006-11-01T18:36:31Z

‎Specification

Manus: Updated to the final release of 5.7

2006-11-01T18:35:07Z

Updated to the final release of 5.7

Zoran: /* Handling projects being opened several times at once */

2006-10-31T10:52:15Z

‎Handling projects being opened several times at once

Patrickr: ProjectFiles moved to ProposalProjectFiles: This is a proposal and does not reflect the implemented solution.

2006-10-30T20:00:15Z

ProjectFiles moved to ProposalProjectFiles: This is a proposal and does not reflect the implemented solution.

Patrickr at 17:53, 6 September 2006

2006-09-06T17:53:15Z

Zoran: /* What does this bring us? */

2006-05-30T07:01:42Z

‎What does this bring us?

Zoran: /* Pseudo-code algorithm */

2006-05-30T06:57:53Z

‎Pseudo-code algorithm

Zoran: /* Pseudo-code algorithm */

2006-05-30T06:44:01Z

‎Pseudo-code algorithm

Zoran: /* Specification */

2006-05-30T06:36:17Z

‎Specification

Zoran at 06:34, 30 May 2006

2006-05-30T06:34:58Z

@@ Line 19: / Line 19: @@
 == Specification ==
 * It should be possible to have different targets of the same project compiled with different versions of estudio, situations in which this is useful:
 ** one wants to compile a 'win32' and 'win64' version of the same project

@@ Line 7: / Line 7: @@
 Currently, 5.7 offers the following status on project files:
 * a .ecf file describes the Eiffel system to compile, without any compiled-project specific info (see [[Configuration]])
-* .ecf files used to be called .acex, but this has been abandoned in favor of the .ecf extension
+* compiled-project specific info is stored in a user file in the user home directory
-* compiled-project specific info is stored in a .user file in the same folder as the .ecf
+* the user file is a stored object of type USER_OPTIONS
-* the .user file resides in the same folder as the corresponding .ecf
-* the .user file is a stored object of type USER_OPTIONS
 * [[ConfigurationMigration]] page describes how .ace files are migrated to the new .ecf format, and gives some info on the compiled-project files structure
 * a folder called '''EIFGENs''' holds all the files representing a compiled project
-* the .user file contains the path to the EIFGENs folder
+* the user file contains the path to the EIFGENs folder
-* it is possible to have the .ecf and .user files in another folder than the one containing the EIFGENs (but it is not possible to share the same .user file for different users and machines)
+* it is possible to have the .ecf in another folder than the one containing the EIFGENs (but it is not possible to share the same user file for different users and machines)
 There are some limitations to the current implementation
-* the .ecf file can not be used from a network share (the .user file will contain info relative to the machine that performed the compilation, like a path to the EIFGENs folder that is meaningful only from the machine that created the project)
+* the user file could contain more info allowing a more coherent management of Eiffel projects. For example, opening the same project several times at once usually leads to project corruption, and there is no way to know whether a project is already open or not
-* if the .ecf file is not in the same folder as the EIFGENs, the .user file bounds it to that folder anyway, we might as well then fix the location of the EIFGENs folder and have it necessarily be in the same folder as the .ecf
-* the .user file could contain more info allowing a more coherent management of Eiffel projects, the following scenarios are not handled correctly right now:
-** a group of developers wants to share the same .ecf file, but have different compilation folders
-** if a user compiles a project with environment variable GOBO defined for example, then closes the project, reopens it but forgets to define GOBO this time around, the compiler fails with an obscure error stating that "/library/kernel" is missing, the user has to guess that GOBO is not defined...
-** opening the same project several times at once usually leads to project corruption, and there is no way to know whether a project is already open or not
 == Specification ==

@@ Line 266: / Line 266: @@
 	<lock
 		estudio="5.7.58953"
 		host="zebra3.example.com"
 		username="marty"
@@ Line 308: / Line 309: @@
 end
 </code>
 === Command-line arguments for 'ec' and 'estudio' ===

@@ Line 3: / Line 3: @@
 [[Category:Compiler]]
 [[Category:Projects]]
 == Rationale ==
 Currently, 5.7 offers the following status on project files:

@@ Line 193: / Line 193: @@
 ==== What does this bring us? ====
 * it is possible to open an eiffel project from a .ecp file, with the right version of estudio, environment settings etc.
-* is is possible to recompile a project from scratch from a .ecp file easily (all the needed info is there)
+* it is possible to recompile a project from scratch from a .ecp file easily (all the needed info is there)
 * if environment variables changed since the project was compiled, the user can be warned

← Older revision	Revision as of 20:00, 30 October 2006
(No difference)

@@ Line 415: / Line 415: @@
 				mismatches.extend (var)
 			end
-		-- apply similar comparison for ecp.host and ecp.username
+		--apply similar comparison for ecp.host and ecp.username
 		if not mismatches.is_empty then
 			if gui_mode then
@@ Line 425: / Line 425: @@
 			end
 		end
 		--check that EIFGENs exists, if not create it
 		--create .lock file

@@ Line 28: / Line 28: @@
 * Opening an already compiled project should restore the environment as it was when project was compiled (as much as possible, for coherence)
 * It should be possible to instruct the compiler to recompile a project from scratch using that same file
-* It should be possible for third party tools (other than estudio compiler itself) to work with that project descrition file (why not, many people could contribute tools that work with estudio projects)
+* It should be possible for third party tools (other than estudio compiler itself) to work with that project description file (why not, many people could contribute tools that work with estudio projects)
 * We consider that the situation of opening a project from estudio itself is covered no matter what we choose (estudio will always show an "open project" dialog that will list previously compiled projects and will allow to create a new project using a wizard)
 * The interesting bits are for "batch" or "automated" project creation and compilation