IDE: Save Project As.. .Project file not updated

[GoogleCodeExporter]

1) Describe the problem.

The Save Project As.. logic does not update the .project file in the target 
directory.  In particular, ExecPath is left pointing at the old project name.

(and thus trying to make the executable in the new project results in the 
executable name being the same as the old one.)

2) GIVE THE FOLLOWING INFORMATIONS (if they are appropriate):

Version: TRUNK
Revision: r5164
Operating system: Linux
Distribution: PCLinuxOS
Architecture: x86
GUI component: QT4
Desktop used: LXDE

3) Provide a little project that reproduces the bug or the crash.
N/A

4) If your project needs a database, try to provide it, or part of it.
N/A

5) Explain clearly how to reproduce the bug or the crash.
See above

6) By doing that carefully, you have done 50% of the bug fix job!

IMPORTANT NOTE: if you encounter several different problems or bugs, (for
example, a bug in your project, and an interpreter crash while debugging
it), please create distinct issues!

Original issue reported on code.google.com by adamn...@gmail.com on 13 Sep 2012 at 3:42

[GoogleCodeExporter]

Original comment by benoit.m...@gmail.com on 13 Sep 2012 at 9:05

• Changed state: Accepted
• Added labels: Version-3.2.0
• Removed labels: Version

[GoogleCodeExporter]

If the executable is generated inside the project directory (the default), then 
the path is relative. So there is no need to change it when saving the project 
with another name.

Otherwise, the executable path is absolute. Then what should be the new path? 
Do you mean just replacing the old project name by the new project name inside 
the path?

Original comment by benoit.m...@gmail.com on 14 Sep 2012 at 11:59

• Changed state: NeedsInfo

[GoogleCodeExporter]

OK.
1) This depends on the original project (let's call it "Orig") having an entry 
in its .project file "ExecPath=". (Say, by someone using Make Executable and 
changing the output directory in FMakeExecutable to somewhere other than the 
"Orig" project directory.)
2) When someone opens "Orig" after that and makes a copy of the project as say 
"NewProj", the "Orig" .project file is copied into the "NewProj" directory as 
is. (That is, it contains the ExecPath= entry.)
3) When the new project is opened (automatically or otherwise), 
Project.ReadProject() at line 3172 encounters that entry and sets 
Project.ExecPath to its value.
4) Now we move to Project.MakeExecutable() around lines 2760-2765.  
    sExecPath = GetExecPath()  <--- (a)
    If Not Exist(File.Dir(sExecPath)) Then sExecPath = Project.Dir &/ File.Name(sExecPath)

    'IF Dialog.SaveFile() THEN RETURN TRUE
    sExecPath = FMakeExecutable.Run(sExecPath) <--- (b)

(a) getExecPath will return the value of Project.ExecPath, which can be a valid 
and existing path, but the one where the "Orig" project was compiled in step 1

so (finally!) at (b) instead of the FMakeExecutable FileChooser ("fchExec") 
pointing to the "NewProj" directory it is pointing to where "Orig" was compiled 
and the file name is the original name.

What actually happened here was that Felicity compiled the "orig" project, 
which is a boilerplate project to a shared testing directory on our source 
server, I then made a copy of it as a new project.  When I compiled the new 
one, I didn't look at the FMakeExecutable form too closely, expecting that it 
would just compile it into my new project directory.  I then opened a terminal 
using Tools|Open A Terminal and there was no executable there.  Much confusion 
then occurred because I couldn't find my executable and Felicity's version 
magically changed!

So, to answer your question, I feel that the ExecPath= entry in the old 
.project should not be copied into the new .project file.  This is based on 
considering the possible reasons for making a copy of a project, all the ones 
that I can think of relate to the idea of copying the source for some other 
purpose and none include retaining information about where the original project 
was compiled to.

Sorry the original issue description was incomplete, it seemed so obvious to me.
B

Original comment by adamn...@gmail.com on 15 Sep 2012 at 1:37

[GoogleCodeExporter]

OK, got it :-)

Original comment by benoit.m...@gmail.com on 17 Sep 2012 at 1:18

• Changed state: Started

[GoogleCodeExporter]

Fixed in revision #5172.

Original comment by benoit.m...@gmail.com on 17 Sep 2012 at 1:42

• Changed state: Fixed