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

By elsewhere, do you mean not in the CDT?

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



David Inglis <dinglis@xxxxxxx> 
Sent by: cdt-dev-admin@xxxxxxxxxxx
10/07/2003 08:22 AM
Please respond to
cdt-dev@xxxxxxxxxxx


To
cdt-dev@xxxxxxxxxxx
cc

Subject
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);=
>

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




Back to the top