Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Patch proposal for bug 44134

I guess the main objective would be to get fixes to P1 problems in before 
the RC1 build so that we can hopefully make this the last RC. Right now we 
have 3 of those. There's no chance we'll be done tomorrow knowing one of 
them.

43174 
maj 
P1 
Oth 
gheorghe@xxxxxxxxxx 
NEW 
1.2 
Code Assist take a long time to find Classes in ManyClass... 
44134 
cri 
P1 
PC 
sevoy@xxxxxxxxxx 
REOP 
1.2 
Managed: Empty dependent project causes infinite loop 
44220 
cri 
P1 
All 
dinglis@xxxxxxx 
ASSI 
1.2 
Make Target view can cause dead lock with UI Thread 

I'd like to do the build Wed morning, noon EST at the latest.  If the 
owners of the P1s don't think they'll make that could you let us know 
ASAP.

Cheers,
Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada



Kleanthis Hapitas/Ottawa/IBM@IBMCA 
Sent by: cdt-dev-admin@xxxxxxxxxxx
10/06/2003 05:34 PM
Please respond to
cdt-dev@xxxxxxxxxxx


To
cdt-dev@xxxxxxxxxxx
cc

Subject
Re: [cdt-dev] Patch proposal for bug 44134







Hey guys, 

Just wanting to make sure we are all on the same page regarding the next 
release candidate for CDT 1.2.  Sean E. submitted a patch for bug 44134, 
and Dave I. submitted a patch for bug 44220. 

I saw one +1 for Sean's patch (no vetoes), but nothing either way for 
Dave's patch... 

In the interest of getting the next RC build out in time to actually meet 
the goal of getting the final build ready by Oct 14, it should happen 
sometime within the next day or so. We should set a target time for the 
RC1 build, so the committers have a timeframe to work with to either vote 
for or reject a patch. How does tomorrow (Oct. 7) at noon sound as a 
cutoff Or maybe end of business? That would allow three full days to poke 
at RC1 this week, and assuming all is well declare victory next Tuesday 
(Monday is a Holiday in Canada). 

Sound reasonable? 

Kleo Hapitas
Program Manager
IBM Software Group - Rational
Tel: (613) 591 2913 



Douglas Schaefer/Ottawa/IBM@IBMCA 
Sent by: cdt-dev-admin@xxxxxxxxxxx 
10/06/2003 03:00 PM 

Please respond to
cdt-dev@xxxxxxxxxxx


To
cdt-dev@xxxxxxxxxxx 
cc
cdt-dev@xxxxxxxxxxx, cdt-dev-admin@xxxxxxxxxxx, cdt-patch@xxxxxxxxxxx 
Subject
Re: [cdt-dev] Patch proposal for bug 44134








If there are no vetoes by tomorrow morning, I'll apply this patch for the 
RC1 build.

Cheers,
Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada



Sean Evoy/Ottawa/IBM@IBMCA 
Sent by: cdt-dev-admin@xxxxxxxxxxx
10/06/2003 11:44 AM
Please respond to
cdt-dev@xxxxxxxxxxx


To
cdt-dev@xxxxxxxxxxx
cc
cdt-patch@xxxxxxxxxxx
Subject
Re: [cdt-dev] Patch proposal for bug 44134






Thanks Brent,
Good catch. Revised patch attached.



Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada




Brent Nicolle/Ottawa/IBM@IBMCA 
Sent by: cdt-dev-admin@xxxxxxxxxxx
10/06/2003 10:37 AM
Please respond to
cdt-dev@xxxxxxxxxxx


To
cdt-dev@xxxxxxxxxxx
cc

Subject
Re: [cdt-dev] Patch proposal for bug 44134






Hi Sean,

The second minus sign should be deleted; that is:
       -cd <dep_project_build_dir> && -$(MAKE) clean all
should read:
       -cd <dep_project_build_dir> && $(MAKE) clean all

The initial minus sign is consumed by Make. The rest of the line, after 
macro expansion, is passed on to the shell which would interpret 
unsuccessfully the second minus sign as a command:
       /bin/sh: -: not found 

Otherwise, this is a clever low-risk change to a bad problem.

- Brent




Sean Evoy/Ottawa/IBM@IBMCA 
Sent by: cdt-dev-admin@xxxxxxxxxxx
10/03/2003 05:00 PM
Please respond to
cdt-dev@xxxxxxxxxxx


To
cdt-dev@xxxxxxxxxxx
cc

Subject
[cdt-dev] Patch proposal for bug 44134






Hi All,
I have a simple patch proposal for a critical bug, 44134. The problem lies
in how the makefile is generated when a build target references other
projects. The makefile creates a command to change to the build directory
of the referenced project and call $(MAKE) there, i.e.

cd <dep_project_build_dir>; $(MAKE) clean all

The problem arises when the directory change fails. As of RC0, the command
after the semi-colon is evaluated. Unfortunately, it evaluates to a
recursive make call in the build directory of the build target and 'make'
will keep invoking more 'make's until Eclipse runs out of memory. With a
manual build, the user can still cancel the build. When autobuild is
turned on, they cannot. The only way to shut down Eclipse under that
scenario is to kill it, and when it restarts, autobuild is still enabled
and the problem repeats.

The best solution is to ignore dependencies on empty projects, but the
simplest (and more generally applicable) solution is to NOT perform the
'make' command if the 'cd' fails, i.e.

cd <dep_project_build_dir> && $(MAKE) clean all

When the dependencies are generated this way, the 'cd' will fail as will
the build. The final tweak is to ignore the 'cd' failure and allow the
rest of the build to continue, i.e.

-cd <dep_project_build_dir> && -$(MAKE) clean all

I think that this is a legitimate problem that is severe enough to justify
a new RC. The patch amounts to a 2-line change in my code, and has no
impact on the rest of the build system.

I would like to get a committer vote on this proposal. I have included the
patch so you can evaluate the delta.

Thanks,

Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada




#### cdt-managedbuilder-core-patch.txt has been removed from this note on 
October 06, 2003 by Brent Nicolle

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev



Index: ChangeLog
===================================================================
RCS file: /home/tools/org.eclipse.cdt.managedbuilder.core/ChangeLog,v
retrieving revision 1.13
diff -u -r1.13 ChangeLog
--- ChangeLog	2 Oct 2003 02:56:46 -0000	1.13
+++ ChangeLog	6 Oct 2003 14:47:41 -0000
@@ -1,3 +1,29 @@
+2003-10-03 Sean Evoy
+	Fix for critical bug 44134. 
+	
+	The problem lies in how the makefile is generated when a build target 
+	references other projects. The makefile creates a command to change to 
+	the build directory of the referenced project and call $(MAKE) there, i.e.
+		cd <dep_project_build_dir>; $(MAKE) clean all 
+
+	The problem arises when the directory change fails. As of RC0, the command 
+	after the semi-colon is evaluated. Unfortunately, it evaluates to a recursive 
+	make call in the build directory of the build target and 'make' will keep 
+	invoking more 'make's until Eclipse runs out of memory. With a manual build, 
+	the user can still cancel the build. When autobuild is turned on, they cannot. 
+	The only way to shut down Eclipse under that scenario is to kill it, and when 
+	it restarts, autobuild is still enabled and the problem repeats.
+
+	The solution is to NOT perform the 'make' command if the 'cd' fails, i.e.
+		cd <dep_project_build_dir> && $(MAKE) clean all 
+
+	When the dependencies are generated this way, the 'cd' will fail as will the 
+	build. The final tweak is to ignore the 'cd' failure and allow the rest of 
+	the build to continue, i.e.
+		-cd <dep_project_build_dir> && $(MAKE) clean all 
+		
+	*  src/org/eclipse/cdt/managedbuilder/internal/core/MakefileGenerator.java
+
 2003-10-01 Sean Evoy
 	Final fix for bugs 44020.
 	The problem lay with the way that new projects were being created when the 
Index: src/org/eclipse/cdt/managedbuilder/internal/core/MakefileGenerator.java
===================================================================
RCS file: /home/tools/org.eclipse.cdt.managedbuilder.core/src/org/eclipse/cdt/managedbuilder/internal/core/MakefileGenerator.java,v
retrieving revision 1.9
diff -u -r1.9 MakefileGenerator.java
--- src/org/eclipse/cdt/managedbuilder/internal/core/MakefileGenerator.java	1 Oct 2003 14:25:35 -0000	1.9
+++ src/org/eclipse/cdt/managedbuilder/internal/core/MakefileGenerator.java	6 Oct 2003 14:47:42 -0000
@@ -68,7 +68,7 @@
 	protected static final String MODFILE_NAME = "subdir.mk";	//$NON-NLS-1$
 	protected static final String LINEBREAK = "\\";
 	protected static final String NEWLINE = System.getProperty("line.separator");
-	protected static final String SEMI_COLON = ";";
+	protected static final String LOGICAL_AND = "&&";
 	protected static final String SEPARATOR = "/";
 	protected static final String TAB = "\t";	
 	protected static final String WHITESPACE = " ";
@@ -562,7 +562,7 @@
 						}
 						managedProjectOutputs.add(buildDir + SEPARATOR + depPrefix + depTarget);
 					}
-					buffer.append(TAB + "cd" + WHITESPACE + buildDir + SEMI_COLON + WHITESPACE + "$(MAKE) " + depTargets + NEWLINE);
+					buffer.append(TAB + "-cd" + WHITESPACE + buildDir + WHITESPACE + LOGICAL_AND + WHITESPACE + "$(MAKE) " + depTargets + NEWLINE);
 				}
 			}
 			buffer.append(NEWLINE);

Back to the top