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

44220 has be resolved, turns out to not be a problem in the target content provider but elsewhere.

Dave.

Kleanthis Hapitas wrote:


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