Re: Intermittent parallel make rebuild failures
David Highley wrote: Philip Guenther wrote: Looking backwards, this rule from your top level makefile: $(INF_DIST_SVCS_OBJS): $(DIRS) seems bogus, given that $(INF_DIST_SVCS_OBJS) is a list of objects in directories _below_ the list of directories in $(DIRS). The top level make may recurse, then on popping back out see that the *SOURCE DIRECTORY* didn't change, and thereby decide that the object must not have changed. OK, the fix ended up being fairly minor to implement. We replaced the $(DIRS) target with: $(INF_DIST_SVCS_OBJS): $(INF_DIST_SVCS_SCRS) @$(SET_E); $(MKDIR) $(@D); cd $(@D)/.. \ PATH=$(PATH) $(MAKE) $(OBJDIR)/$(@F) Had to create another macro $(INF_DIST_SVCS_SCRS) which is defined as: INF_DIST_SVCS_SCRS = $(foreach DIR,$(DIRS),$(wildcard $(DIR)/*.cpp)) We still need to had a filter capability to the macro yet. Testing has shown this to be solid and you get the message that your object file is up to date for each object file that does not need to change. Well, as is the case with most software development we still had issues. The real issue seems to be the early evaluation of prerequisites and also not having enough knowledge of the code at the upper level make location. So while the fix ended up being minor the discovery was a long process. We ended up adding a recursion at the top level: all: $(DIRS) $(SET_E); PATH=$(PATH) $(MAKE) $(LIBRARY) So in the end we removed the new macro that only provided knowledge of the body files and not the header files so it was still an incomplete solution. I did get a synopsis of our build process pushed to the web with some overview documentation. We would appreciate any feedback and we hope that others can find useful working examples from this build process. This build system and our applications work across Solaris, Linux, Windows, and VxWorks. While the newer WindRiver tool sets are a little easier to work with it still requires some separate build process when you are constructing the application image. If you are just building support libraries it can be done like other platforms. All of our builds use relative paths and require Cygwin for the Windows platform, and for the VxWorks builds as the tool set is hosted on Windows. All of our compilers are checked into ClearCase, but the build process is independent of ClearCase except for how we build version identification into the build products. http://www.highley-recommended.com/make_process/index.html It looks me like your makefile is misleading make. Can you give examples of the output of make when this stuff *isn't* working? Preferable minimal, of course, where only a single source file was changed/recompiled, showing how make failed to rebuild everything that it you wish it would, and then the output of the second make invocation that builds the missing piece?ou I don't trust dependencies on directories; you have a dependency on a directory WHOSE CONTENTS AREN'T BEING CHANGED. That raises florescent red flags to me. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
Looking backwards, this rule from your toplevel makefile: $(INF_DIST_SVCS_OBJS): $(DIRS) seems bogus, given that $(INF_DIST_SVCS_OBJS) is a list of objects in directories _below_ the list of directories in $(DIRS). The toplevel make may recurse, then on popping back out see that the *SOURCE DIRECTORY* didn't change, and thereby decide that the object must not have changed. It looks me like your makefile is misleading make. Can you give examples of the output of make when this stuff *isn't* working? Preferable minimal, of course, where only a single source file was changed/recompiled, showing how make failed to rebuild everything that it you wish it would, and then the output of the second make invocation that builds the missing piece?ou I don't trust dependencies on directories; you have a dependency on a directory WHOSE CONTENTS AREN'T BEING CHANGED. That raises florescent red flags to me. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
Philip Guenther wrote: Looking backwards, this rule from your top level makefile: $(INF_DIST_SVCS_OBJS): $(DIRS) seems bogus, given that $(INF_DIST_SVCS_OBJS) is a list of objects in directories _below_ the list of directories in $(DIRS). The top level make may recurse, then on popping back out see that the *SOURCE DIRECTORY* didn't change, and thereby decide that the object must not have changed. OK, the fix ended up being fairly minor to implement. We replaced the $(DIRS) target with: $(INF_DIST_SVCS_OBJS): $(INF_DIST_SVCS_SCRS) @$(SET_E); $(MKDIR) $(@D); cd $(@D)/.. \ PATH=$(PATH) $(MAKE) $(OBJDIR)/$(@F) Had to create another macro $(INF_DIST_SVCS_SCRS) which is defined as: INF_DIST_SVCS_SCRS = $(foreach DIR,$(DIRS),$(wildcard $(DIR)/*.cpp)) We still need to had a filter capability to the macro yet. Testing has shown this to be solid and you get the message that your object file is up to date for each object file that does not need to change. It looks me like your makefile is misleading make. Can you give examples of the output of make when this stuff *isn't* working? Preferable minimal, of course, where only a single source file was changed/recompiled, showing how make failed to rebuild everything that it you wish it would, and then the output of the second make invocation that builds the missing piece?ou I don't trust dependencies on directories; you have a dependency on a directory WHOSE CONTENTS AREN'T BEING CHANGED. That raises florescent red flags to me. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
Philip Guenther wrote: On Thu, Oct 7, 2010 at 9:22 AM, David Highley dhigh...@highley-recommended.com wrote: ... Let us just cut to the essence of the issue we are running into, how do target prerequisites get processed in version 3.81 of make? Example: $(LIBRARY): $(INF_DIST_SVCS_OBJS) $(INF_DIST_SVCS_OBJS): $(DIRS) $(DIRS): .PHONY: $(DIRS) With parallel building how does the macro $(INF_DIST_SVCS_OBJS) get evaluated before the target $(DIRS) is done? Is there a method to stop this other than turning parallel building off? Have you read the info pages section How `make' Reads a Makefile? In it, it explains that variables in targets and prerequisite lists are expanded immediately when the rule is read during the parsing of the Makefile. So, *before any targets have been built*, $(INF_DIST_SVCS_OBJS) will be expanded twice during the parsing of the above Makefile snippet, once when the $(LIBRARY) rule is parsed and once when the $(INF_DIST_SVCS_OBJS) rule is parsed. Yes I know the normal order of processing of includes, macros, and targets. I will say that I have some that use $@ which is only defined when the target is executed can work. The -j option has no effect on that, so I don't understand your last question above. Or are you saying that this makefile is part of a recursive make setup, so that it might be read multiple times, the earlier of which could affect the latter of which? OK, the behavior has been very miss leading in this case. The real issue is that there is no knowledge of the source files at the upper make level yet we are rolling all the lower level created object files into a larger library. Would not need to do this if on UNIX/Linux platforms you could stuff multiple libraries into a collection library and get the linker work right. This does work on Windows, but we need solutions that work across a wide array of platforms. The behavior is such that non parallel builds work every time. If several object files change then it seems to work. If you touch only one source file and build then it will fail most of the time. If you add $(INF_DIST_SVCS_OBJS) to the .PHONY: target it will work every time, but unfortunately it will relink even if no object file changes. If you add an order dependent prerequisite | $(DIRS) to the library target it has no effect. So I'm still working on the right solution. By the way I hope to make available our build process in the near future. I have been working on documenting it and hope that others may find it useful, educating and can provide feedback with their ideas for making it better. It has proven to be light weight and easy to bring up on new projects. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
OK, after more testing I now believe that I have leaped to the Island of Conclusions in the Sea of Wisdom more than once, or more accurately I have fallen into the unconscious incompetent syndrome. Let us just cut to the essence of the issue we are running into, how do target prerequisites get processed in version 3.81 of make? Example: $(LIBRARY): $(INF_DIST_SVCS_OBJS) $(INF_DIST_SVCS_OBJS): $(DIRS) $(DIRS): .PHONY: $(DIRS) With parallel building how does the macro $(INF_DIST_SVCS_OBJS) get evaluated before the target $(DIRS) is done? Is there a method to stop this other than turning parallel building off? I did read the update NEWS and looked through all the backward incompatibles and down loaded the latest manual so I'm really not understanding what is causing this issue. The target $(DIRS) does invoke sub make processes but I do not see the why that would matter in the context of understanding how the prerequisites are processed. David Highley wrote: Well, I'm going to have to eat crow on this one. After much digging into this issue, down loading older versions of make back to 3.78.1. Researching our large build process and its history I find that we had disabled parallel building for this one library build in the past. We use the build construct describe before all over our build process and I find only this one library build where we disabled parallel building for the top makefile. I can find nothing unique about this library build as compared to our other library builds so I'm still not able to understand why we need to disable parallel building for this one library. Note the disabling is only for the top makefile, all the sub makes are still parallel which in effect means that only one source directory has sub make launched at a time. We have larger library builds and we have smaller library builds so we see no reason why this one exhibits a parallel build issue. What I also found was the lack of comments for the reason we disabled parallel building before, which I have now corrected. I did retest with the current version of make 3.82 and found no issue. But since I only did testing with the problematic area I'm not able say whether it works in general. Paul, if you would like me to do a larger test with the latest version let me know and I can work that in. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
On Thu, Oct 7, 2010 at 9:22 AM, David Highley dhigh...@highley-recommended.com wrote: ... Let us just cut to the essence of the issue we are running into, how do target prerequisites get processed in version 3.81 of make? Example: $(LIBRARY): $(INF_DIST_SVCS_OBJS) $(INF_DIST_SVCS_OBJS): $(DIRS) $(DIRS): .PHONY: $(DIRS) With parallel building how does the macro $(INF_DIST_SVCS_OBJS) get evaluated before the target $(DIRS) is done? Is there a method to stop this other than turning parallel building off? Have you read the info pages section How `make' Reads a Makefile? In it, it explains that variables in targets and prerequisite lists are expanded immediately when the rule is read during the parsing of the Makefile. So, *before any targets have been built*, $(INF_DIST_SVCS_OBJS) will be expanded twice during the parsing of the above Makefile snippet, once when the $(LIBRARY) rule is parsed and once when the $(INF_DIST_SVCS_OBJS) rule is parsed. The -j option has no effect on that, so I don't understand your last question above. Or are you saying that this makefile is part of a recursive make setup, so that it might be read multiple times, the earlier of which could affect the latter of which? Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
Paul, Since yesterday was very hectic I decided to go back and re-run all my testing for the intermittent parallel build failure. I have now concluded that Red Hat 5.4 also does not work so the last know working version was a 3.79-x version which came on Red Hat 3 Update 8. I did retest the latest version 3.82 down loaded from savannah.gnu.org and it also does not work. Let me know how I can further support getting this issue fixed. Paul Smith wrote: On Tue, 2010-10-05 at 11:07 -0700, David Highley wrote: The latest version of Fedora 13 does not have a 3.82 version of make so the only way to test would be to build from source which I can do. It may take me a while since were pretty busy right now. Building make from source is pretty trivial: only one binary (plus docs). You can just run it out of the build directory if you want, no need to install. But no huge rush: I'm underwater at work for at least the next few weeks as well. Do we know if anyone is working on a newer update for Cygwin? I don't; maybe a message to make-...@gnu.org would help? I really don't follow this at all (I know, lucky, right? :-)) but my vague impression is that people are moving away from Cygwin and towards mingw. Paul has it really only been 15 years. I though our discussions went back to 1995 or so when you were working a Bay Networks. Well, I've been using GNU make heavily since 1988 or 1989 so it's likely we did have those discussions. But I took over maintainer ship from Roland in 1996 (as best as I recall). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
Every time the subject of cache comes up its because they are always wrong. well, this *is* a *bug* list - every time anything comes up here, it's because someone's found a bug in it ! The vast amount of the time that the cache works just fine and makes builds faster is (quite properly) not normally the subject of posts to the bug-make list ... Eddy. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
Edward Welbourne wrote: Every time the subject of cache comes up its because they are always wrong. well, this *is* a *bug* list - every time anything comes up here, it's because someone's found a bug in it ! The vast amount of the time that the cache works just fine and makes builds faster is (quite properly) not normally the subject of posts to the bug-make list ... That's the issue, things used to work reliably. Now we seem to accept that they work most of the time. So far I find no acceptable way of modifying this build to be reliable. Here is the tough part of trying to fix this issue. If your trying to support a large build system and have consistency across subsystems and minimize multiple typing of code to minimize maintenance failures then it is very hard to solve this issue. So far the only way I have been able to get the build to work it to add the macro $(DIRS) to the dependency line and change the $(LINK) macro not to use $^ but to use $(INF_DIST_SVCS_OBJS) which totally breaks any kind of maintainability across a large build system. In the information provided the macro $(LINK) can be one of: LINK_STATIC = \ PATH=$(PATH) \ $(AR) \ $(AR_OUT) \ $^ LINK_SHARED = \ PATH=$(PATH) \ LD_LIBRARY_PATH=$(LD_LIBRARY_PATH) \ $(LD) \ $(LD_OUT) \ $(LIB_NAME) \ $(LDXFLAGS) \ $(LDBFLAGS) \ $^ LINK_DLL= \ PATH=$(PATH) \ LD_LIBRARY_PATH=$(LD_LIBRARY_PATH) \ $(LD) \ $(LD_OUT) \ $(LIB_NAME) \ $(LDXFLAGS) \ $(LDBFLAGS) \ $^ \ $(LIBS) \ $(PLATFORM_LIBS) \ $(MANIFEST) Eddy. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
David Highley wrote: Edward Welbourne wrote: Every time the subject of cache comes up its because they are always wrong. well, this *is* a *bug* list - every time anything comes up here, it's because someone's found a bug in it ! The vast amount of the time that the cache works just fine and makes builds faster is (quite properly) not normally the subject of posts to the bug-make list ... Good news, it appears that Red Hat 5.4 with GNU make 3.81-3 fixes the issue we are running into. Now to find the right version for Cygwin. That's the issue, things used to work reliably. Now we seem to accept that they work most of the time. So far I find no acceptable way of modifying this build to be reliable. Here is the tough part of trying to fix this issue. If your trying to support a large build system and have consistency across subsystems and minimize multiple typing of code to minimize maintenance failures then it is very hard to solve this issue. So far the only way I have been able to get the build to work it to add the macro $(DIRS) to the dependency line and change the $(LINK) macro not to use $^ but to use $(INF_DIST_SVCS_OBJS) which totally breaks any kind of maintainability across a large build system. In the information provided the macro $(LINK) can be one of: LINK_STATIC = \ PATH=$(PATH) \ $(AR) \ $(AR_OUT) \ $^ LINK_SHARED = \ PATH=$(PATH) \ LD_LIBRARY_PATH=$(LD_LIBRARY_PATH) \ $(LD) \ $(LD_OUT) \ $(LIB_NAME) \ $(LDXFLAGS) \ $(LDBFLAGS) \ $^ LINK_DLL= \ PATH=$(PATH) \ LD_LIBRARY_PATH=$(LD_LIBRARY_PATH) \ $(LD) \ $(LD_OUT) \ $(LIB_NAME) \ $(LDXFLAGS) \ $(LDBFLAGS) \ $^ \ $(LIBS) \ $(PLATFORM_LIBS) \ $(MANIFEST) Eddy. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make -- Regards, David Highley Highley Recommended, Inc. Phone: (206) 669-0081 2927 SW 339th StreetWEB: http://www.highley-recommended.com Federal Way, WA 98023-7732 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
On Tue, 2010-10-05 at 10:23 -0700, David Highley wrote: Good news, it appears that Red Hat 5.4 with GNU make 3.81-3 fixes the issue we are running into. Now to find the right version for Cygwin. I'd be really interested to know whether the current latest release of GNU make (3.82) has this problem or not. If not I'll need to go dig up the SRPM for that version of GNU make from Red Hat and find out what patches they've installed. That's the issue, things used to work reliably. Now we seem to accept that they work most of the time. Can you clarify what you mean by used to work reliably? With which version? The directory caching stuff predates my involvement with GNU make, so it's at least 15 years old. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
Paul Smith wrote: On Tue, 2010-10-05 at 10:23 -0700, David Highley wrote: Good news, it appears that Red Hat 5.4 with GNU make 3.81-3 fixes the issue we are running into. Now to find the right version for Cygwin. I'd be really interested to know whether the current latest release of GNU make (3.82) has this problem or not. The latest version of Fedora 13 does not have a 3.82 verion of make so the only way to test would be to build from source which I can do. It may take me a while since were pretty busy right now. If not I'll need to go dig up the SRPM for that version of GNU make from Red Hat and find out what patches they've installed. That's the issue, things used to work reliably. Now we seem to accept that they work most of the time. Can you clarify what you mean by used to work reliably? With which version? The directory caching stuff predates my involvement with GNU make, so it's at least 15 years old. I think Red Hat 3 Update 8 Taroon had version 3.79-1-17.1 of make. Which means there are likely many changes since that time. It appears that the latest version of make for Cygwin is 3.81-2 which still fails for us. So the fix maybe narrowed into a change between 3.81-2 and 3.81-3. Do we know if anyone is working on a newer update for Cygwin? Paul has it really only been 15 years. I though our discussions went back to 1995 or so when you were working a Bay Networks. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
On Tue, 2010-10-05 at 11:07 -0700, David Highley wrote: The latest version of Fedora 13 does not have a 3.82 verion of make so the only way to test would be to build from source which I can do. It may take me a while since were pretty busy right now. Building make from source is pretty trivial: only one binary (plus docs). You can just run it out of the build directory if you want, no need to install. But no huge rush: I'm underwater at work for at least the next few weeks as well. Do we know if anyone is working on a newer update for Cygwin? I don't; maybe a message to make-...@gnu.org would help? I really don't follow this at all (I know, lucky, right? :-)) but my vague impression is that people are moving away from cygwin and towards mingw. Paul has it really only been 15 years. I though our discussions went back to 1995 or so when you were working a Bay Networks. Well, I've been using GNU make heavily since 1988 or 1989 so it's likely we did have those discussions. But I took over maintainership from Roland in 1996 (as best as I recall). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
Paul Smith wrote: On Tue, 2010-10-05 at 11:07 -0700, David Highley wrote: The latest version of Fedora 13 does not have a 3.82 verion of make so the only way to test would be to build from source which I can do. It may take me a while since were pretty busy right now. Building make from source is pretty trivial: only one binary (plus docs). You can just run it out of the build directory if you want, no need to install. But no huge rush: I'm underwater at work for at least the next few weeks as well. OK, I down loaded and did a build of 3.82 on both Red Hat 5.1 and Red Hat 5.4 and it fails in the same way as 3.81-1 and 3.81-2. So 3.82 seems to regress for this issue. Do we know if anyone is working on a newer update for Cygwin? I don't; maybe a message to make-...@gnu.org would help? I really don't follow this at all (I know, lucky, right? :-)) but my vague impression is that people are moving away from cygwin and towards mingw. Paul has it really only been 15 years. I though our discussions went back to 1995 or so when you were working a Bay Networks. Well, I've been using GNU make heavily since 1988 or 1989 so it's likely we did have those discussions. But I took over maintainership from Roland in 1996 (as best as I recall). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Intermittent parallel make rebuild failures
We have a build process that had no issues in the past when we were on Red Hat 3 and an older version of Cygwin. Now our core library builds fail to link intermittently on a rebuild when building on Red Hat 5.1 and Windows using Cygwin make and Windows compilers. I did some digging into it today and find that it is failing about half the time. I copied code out of ClearCase and also moved it to the server hard drive to eliminate networking and possible cache interference. For Linux the GNU make is version 3.81-1. Build works every time if we do not parallel build but it would take for ever to build single threaded. When it fails if you re-run make it does no work except to link the library. So it appears from running make with the debug option that the top level make does not see the object file created by the lower level make in the time when it checks the dependencies for the library. I did more checking with strace and see only one fstat for the library when the build fails to link and two when it succeeds. I see a few bug reports about parallel builds failing and no resolution. Test scenario: - touch ../src/alarmSvc/AlarmPublisherImpl.cpp - make -j 16 DEPFILES= DEBUG= MC_INTERFACES_DIR=/view/cm_mc_us_v10.=1_07/vobtags/mc_interfaces linux_make.log 21 Reducing the build process to essential targets and macros. The mkcommondefs.mk file is large so I extracted the macros involved. #- Macros from mkcommondefs.mk file: LIBDBG = _$(LINK_TYPE) OBJDIR = $(OSTYPE)$(LIBDBG) LIBPATH = $(TOP)/cpp/lib/$(OBJDIR) LIBRARY = $(LIBPATH)/$(LIB_PREFIX)$(PROJECT).$(LIB_SO) # Directory list of source code locations. DIRS= \ $(RELSRCPATH)/alarmSvc \ $(RELSRCPATH)/logSvc \ $(RELSRCPATH)/msgSvc \ $(RELSRCPATH)/$(MSGSVCCOTSDIR) \ $(RELSRCPATH)/msgSvcSockMux \ $(RELSRCPATH)/recordSvc \ $(RELSRCPATH)/timeSvc \ $(RELSRCPATH)/utilitySvc FIND_SRCS = $(filter-out $(EXCLUDES), $(wildcard $(DIR)/*.cpp)) FIND_OBJS = $(filter-out $(EXCLUDES), $(patsubst $(DIR)/%.cpp,$(DIR)/$(OBJDIR)/%.$(OBJ_EXT),$(FIND_SRCS))) INF_DIST_SVCS_OBJS = $(foreach DIR,$(DIRS),$(FIND_OBJS)) .SUFFIXES: #- Top level makefile: TOP = ../.. PROJECT = infdistsvcs # Create archive library rule. $(LIBRARY): $(INF_DIST_SVCS_OBJS) $(SET_E); $(MKDIR) $(LIBPATH); $(RM) $@; $(LINK) $(INF_DIST_SVCS_OBJS): $(DIRS) # Build library source code. $(DIRS): @$(SET_E); cd $@ PATH=$(PATH) $(MAKE) # Must be located after all macro dependency targets. Only # dependencies that are defined in a macro cause an order issue. # The dependency macro must also be a dependency for another target. .PHONY: $(DIRS) tests $(TDIRS) clean libclean distclean \ checkout uncheckout docs web help gen_mcis build_mcis actuate #- Leaf makefile where source code is located: # Navigate up to the parent cpp, or java, or whatever directory. TOP= ../../.. include $(TOP)/cpp/bld/mkcommondefs.mk # Here is the opportunity for the designer of the local subproject # to add any def's for the local subproject. #EXTRA_INCS = #EXTRA_LIBS = # Include common build rules share by build process. include $(TOP)/cpp/bld/mkcommonrules.mk # Here is the opportunity for the designer of the local subproject # to add any rules needed by the local subproject. #- Rules file mkcommonrules.mk: # Default rule all: rm_version $(OBJS) # Create library object files, $(OBJS), rule. $(OBJDIR)/%.$(OBJ_EXT): %.cpp $(SET_E); $(MKDIR) $(OBJDIR); $(COMPILE) .PHONY: all rm_version clean libclean distclean updatelibs help Note: The target rm_version is not pertinent to rebuild issue. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
