[Bug #3403] Memory effect on GNUmakefile ?

[nobody]

=================== BUG #3403: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=3403&group_id=99

Changes by: Nicola Pero <n.pero@mi.flashnet.it>
Date: Wed 04/30/2003 at 14:52 (GMT)

            What     | Removed                   | Added
---------------------------------------------------------------------------
         Assigned to | None                      | nico
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
Hi, very interesting example. :-)

Thanks - it's technically not a bug (so I'm closing the bug 
report) as I'll now explain, but it's indeed a "particular" 
and "interesting" behaviour.

NB: 'make clean' is enough, you don't need a 'make distclean' to clear the 
"memory" :-)

You are likely to have a recent version of GCC, which supports 
auto-dependencies.  What you see is a side-effect
of auto-dependencies.  Unfortunately, either you disable
auto-dependencies (which you can do by editing your
GNUSTEP_MAKEFILES/ix86/linux-gnu/config.make and changing AUTO_DEPENDENCIES 
from 'yes' to 'no'), or ... you have to type 'make clean' before recompiling 
projects when you make
those drastic changes to the structure.  In practice I
think that's standard practice, so formally I wouldn't
consider this a bug.

I'll explain a bit why you see this weird behaviour if
you use auto-dependencies.

Auto-dependencies mean that when you compile a .c/.m file,
GCC can output a .d file, listing what .c/.m/.h files where
used during the compilation.  gnustep-make takes
advantage of this feature if available (in your case,
you find the .d file in ./obj/main.d).

gnustep-make can use this information the next time you
type 'make'.  It looks up the .d file, and knows what 
.h files (or actually, even what other .c or .m files)
where used to compile the .c/.m file.  If the .c/.m file
is changed, it of course recompiles it.  But when
auto-dependencies is used, by looking at the GCC .d output,
it can also check if the .h files used by the .c/.m files 
have changed or not.  If any of them has changed, it 
recompiles the file.

This is generally very useful in practice - gnustep-make/GCC, without any help 
from the programmer,
can automatically determine all the header files which
affect a .c/.m file, and recompile the file if any of the
headers change.  I personally think this is just great.

But a side-effect is that the .d file also lists between
the dependencies the original file.  So in your case,
the .d file is holding the "memory" of the previous .m
file, which no longer exists.  Typing 'make clean'
will remove the .d file, cleaning up the memory.

Unfortunately, either you don't use the .d files (in which
case you don't get autodependencies), or if you use the .d
files, they hold memory of the files used in the previous
compilation, so you see this "memory" effect.



=================== BUG #3403: FULL BUG SNAPSHOT ===================


Submitted by: yjchen                  Project: GNUstep                      
Submitted on: Wed 04/30/2003 at 13:56
Category:  Makefiles                  Severity:  5 - Major                  
Bug Group:  Bug                       Resolution:  None                     
Assigned to:  nico                    Status:  Closed                       

Summary:  Memory effect on GNUmakefile ?

Original Submission:  It seems to be a bug, but I'm not sure.

If files is changed in GNUmakefile from C_FILES to OBJC_FILES
and file extension is changed from .c to .m,
without 'make distclean', it will complain that
the old .c file doesn't exist even the GNUmakefile is updated.
It memorizes the old GNUmakefile in this case.

I use these two files for testing.

GNUmakefile:

include $(GNUSTEP_MAKEFILES)/common.make

# The application to be compiled
TOOL_NAME = Test

# The Objective-C source files to be compiled
Test_OBJC_FILES = main.m

# The C source files to be compiled
Test_C_FILES =

include $(GNUSTEP_MAKEFILES)/tool.make

main.m:
int main(int argc, const char **argv)
{
  printf("Test\n");
  return 0;
}

Compile these two files. Then 'mv main.m main.c',
and change GNUmakefile to include the new main.c in C_FILES
(and comment out OBJC_FILES)
Compile again will complain the old main.m doesn't exist.
Only after 'make distclean' will make it work


Follow-up Comments
*******************

-------------------------------------------------------
Date: Wed 04/30/2003 at 14:52       By: nico
Hi, very interesting example. :-)

Thanks - it's technically not a bug (so I'm closing the bug 
report) as I'll now explain, but it's indeed a "particular" 
and "interesting" behaviour.

NB: 'make clean' is enough, you don't need a 'make distclean' to clear the 
"memory" :-)

You are likely to have a recent version of GCC, which supports 
auto-dependencies.  What you see is a side-effect
of auto-dependencies.  Unfortunately, either you disable
auto-dependencies (which you can do by editing your
GNUSTEP_MAKEFILES/ix86/linux-gnu/config.make and changing AUTO_DEPENDENCIES 
from 'yes' to 'no'), or ... you have to type 'make clean' before recompiling 
projects when you make
those drastic changes to the structure.  In practice I
think that's standard practice, so formally I wouldn't
consider this a bug.

I'll explain a bit why you see this weird behaviour if
you use auto-dependencies.

Auto-dependencies mean that when you compile a .c/.m file,
GCC can output a .d file, listing what .c/.m/.h files where
used during the compilation.  gnustep-make takes
advantage of this feature if available (in your case,
you find the .d file in ./obj/main.d).

gnustep-make can use this information the next time you
type 'make'.  It looks up the .d file, and knows what 
.h files (or actually, even what other .c or .m files)
where used to compile the .c/.m file.  If the .c/.m file
is changed, it of course recompiles it.  But when
auto-dependencies is used, by looking at the GCC .d output,
it can also check if the .h files used by the .c/.m files 
have changed or not.  If any of them has changed, it 
recompiles the file.

This is generally very useful in practice - gnustep-make/GCC, without any help 
from the programmer,
can automatically determine all the header files which
affect a .c/.m file, and recompile the file if any of the
headers change.  I personally think this is just great.

But a side-effect is that the .d file also lists between
the dependencies the original file.  So in your case,
the .d file is holding the "memory" of the previous .m
file, which no longer exists.  Typing 'make clean'
will remove the .d file, cleaning up the memory.

Unfortunately, either you don't use the .d files (in which
case you don't get autodependencies), or if you use the .d
files, they hold memory of the files used in the previous
compilation, so you see this "memory" effect.


CC list is empty


No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=3403&group_id=99