[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug #3403] Memory effect on GNUmakefile ?
From: |
nobody |
Subject: |
[Bug #3403] Memory effect on GNUmakefile ? |
Date: |
Wed, 30 Apr 2003 10:52:01 -0400 |
=================== 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