[
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);
