Two longstanding gripes with my codebase...

[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...

1. 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.
2. 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.

[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.

[xenos]

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...

[Neolander]

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...

[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

[qw]

Do a "make clean" before modifying the Makefile.

[schilds]

That requires extra typing!

[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 $@

[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.

[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).

[Neolander]

Alright, then makefile as an universal dependency it'll be. Thanks guys !

[Solar]

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...

[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?

[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.