Page 1 of 1
Two longstanding gripes with my codebase...
Posted: Sat Aug 06, 2011 2:05 am
by Neolander
It has been some time since I've been hacking around two major limitations of my codebase, and I'd like to know if these can be addressed before going further...
- When using GNU make, is there a clean way of making sure everything is rebuilt when the Makefile is modified ? Only thing I can think of is to add "Makefile" to all targets, which sounds like a horrible idea.
- I currently use a custom build of GCC 4.5.2, with standards -std=c99 for C and -std=c++0x for C++. In C code, I can include the <stdint.h> header without any problem. In C++ code, however, neither <stdint.h> nor <cstdint> are available. Both get the -nostdlib and -ffreestanding parameters. Is anyone else having this problem ? The changelog of GCC 4.6 does not mention it, so I frankly hesitate going through the pain of making a GCC build again if it's only to discover that nothing has changed in this area.
Re: Two longstanding gripes with my codebase...
Posted: Sat Aug 06, 2011 9:09 am
by gravaera
Make the makefile a dependency so if it's modification date is more recent than the target, the target will be rebuilt. It's a pretty well used technique I think.
Re: Two longstanding gripes with my codebase...
Posted: Sat Aug 06, 2011 11:45 am
by xenos
gravaera wrote:Make the makefile a dependency so if it's modification date is more recent than the target, the target will be rebuilt. It's a pretty well used technique I think.
Isn't that exactly what Neo mentioned, and which would require adding the makefile as a dependency to
all targets?
Concerning the C++ header problem: This is exactly what I discuss in my
freestanding C++ compiler thread. Unfortunately I did not find a clean solution yet...
Re: Two longstanding gripes with my codebase...
Posted: Sat Aug 06, 2011 2:39 pm
by Neolander
XenOS wrote:gravaera wrote:Make the makefile a dependency so if it's modification date is more recent than the target, the target will be rebuilt. It's a pretty well used technique I think.
Isn't that exactly what Neo mentioned, and which would require adding the makefile as a dependency to
all targets?
Yup. It worries me a bit as it is both ugly and requires me to think about adding up "Makefile" to all future targets inside of it, though I'm ready to do it if there's no other option.
Concerning the C++ header problem: This is exactly what I discuss in my
freestanding C++ compiler thread. Unfortunately I did not find a clean solution yet...
Guess I'll have to keep my fellow gcc- and arch-specific hack_stdint.h header around for a little while then, and hope the G++ team moves its lazy asm someday...
Re: Two longstanding gripes with my codebase...
Posted: Sat Aug 06, 2011 8:00 pm
by schilds
You could probably make a target that depends on the makefile and cleans all the output (or touches all the input) before all the rest?
e.g.
Code: Select all
all: makeout project
%.out : %.in
cat $< >$@
makeout : makefile
touch *.in
echo>makeout
project : a.out b.out
Re: Two longstanding gripes with my codebase...
Posted: Sun Aug 07, 2011 12:46 am
by qw
Do a "make clean" before modifying the Makefile.
Re: Two longstanding gripes with my codebase...
Posted: Sun Aug 07, 2011 1:59 am
by schilds
That requires extra typing!
Re: Two longstanding gripes with my codebase...
Posted: Sun Aug 07, 2011 3:05 am
by Combuster
Only thing I can think of is to add "Makefile" to all targets, which sounds like a horrible idea.
In the end, that is the only way to do it natively. You can hide it under a ton of abstraction layers, but in the end that will be how it works. Even I do things that way (condensed version posted for clarity,
original here). Notice how I fold all non-source dependencies into only one tag to be added after each relevant rule. If you are doing out-of-tree building you will be doing something similar anyway (you can't build into a directory if it doesn't exists, so that makes another dependency)
Code: Select all
#src-dir-1/Makefile
$(ROOT)output-dir-1: $(ROOT)Makefile $(ROOT)src-dir-1/Makefile
mkdir $(ROOT)output-dir-1
$(ROOT)output-dir-1/%.o: $(ROOT)src-dir-1/%.c $(ROOT)output-dir-1
$(CC) $(CPARMS) $(CFLAGS) $< -o $@
Re: Two longstanding gripes with my codebase...
Posted: Sun Aug 07, 2011 5:22 am
by Solar
I don't exactly see why it would be necessary to add the Makefile to
all targets, or why it would be a horrible idea.
The only rule you have to add the Makefile to is the actual source-to-object step.
From my PDCLib Makefile:
Code: Select all
%.o: %.c Makefile
@$(CC) $(CFLAGS) -MMD -MP -I./includes -c $< -o $@
Note how the inbuilt variable "$<" refers to the
first dependency only (the source file).
All other targets ultimately depend on this step. Since the object file will be rebuilt, the updates will cascade upwards through the dependency tree.
Re: Two longstanding gripes with my codebase...
Posted: Sun Aug 07, 2011 5:32 am
by schilds
Actually now that I've thought about it, touching every input file is probably a bad idea as it would muck around with other tools that depend on file modification time (e.g. version control).
Re: Two longstanding gripes with my codebase...
Posted: Sun Aug 07, 2011 8:07 am
by Neolander
Alright, then makefile as an universal dependency it'll be. Thanks guys !
Re: Two longstanding gripes with my codebase...
Posted: Sun Aug 07, 2011 1:16 pm
by Solar
schilds wrote:Actually now that I've thought about it, touching every input file is probably a bad idea as it would muck around with other tools that depend on file modification time (e.g. version control).
Which version control are you using that depends on mod time? SVN, at least, doesn't...
Re: Two longstanding gripes with my codebase...
Posted: Sun Aug 07, 2011 10:54 pm
by schilds
Don't SVN clients need to determine which files have been recently changed so they can push just those to the repository? I suppose they could store a hash of each file?
Re: Two longstanding gripes with my codebase...
Posted: Sun Aug 07, 2011 11:06 pm
by gerryg400
Don't SVN clients need to determine which files have been recently changed so they can push just those to the repository? I suppose they could store a hash of each file?
Svn clients keep a so-called 'pristine' copy of each file locally so that it can check diffs while you are offline.