#607 .dep files cannot be generated with Clang

[Alexey Dokuchaev]

.dep files are generated with $(CC) -MM command, which include files like <windows.h>, but this does not work with Clang: it will complain on missing file (on Unix), which breaks hardware/r_glide/r_glide.c for example.

Since nowadays Doomlegacy standardized on SDL (at least on Unix), perhaps it makes sense to leave just hardware/r_opengl for hardware.dep:

-../dep/hardware.dep : hardware/*.c hardware/*/*.c
+../dep/hardware.dep : hardware/*.c hardware/r_opengl/*.c

This allows Doomlegacy to be built with Clang.

[Wesley Johnson]

Clang is not generating one of the necessary dependencies ??
Or is it that Clang is choking on having two * in the prerequisites ??

I can have a complete dependency and a comment which explains why it is there.
If it it too strange, it needs to be conditional on compiling with Clang.

I still support linux_x (which has known users), MinGW, and trying to get Mac to work again, so cannot just assume it is SDL only.

[Alexey Dokuchaev]

The problem is that GCC with -MM flag will ignore includes of system-wide headers like <windows.h>, for example, consider this little shell session (on Unix):

$ touch bar.h
$ cat > foo.c 
#include <windows.h>
#include "bar.h"
$ gcc -MM foo.c
foo.o: foo.c bar.h
$ clang -MM foo.c
foo.c:1:10: fatal error: 'windows.h' file not found
#include <windows.h>
         ^
1 error generated.

As you can see, unguarded windows-specific header is ignored by GCC, but upsets Clang. I failed to find command line options to make Clang behave like GCC.

[Wesley Johnson]

Generating dep files on Linux should not have any dep file with
windows.h, that would not work on any Linux system.
I have checked my dep and they do not have windows.h.
Please indicate how you are getting windows.h into the dep file on a
Linux compile. The CFLAGS should select conditional compile sections that
exclude includes of windows.h. Try "make clean" before you compile.
If Clang is doing something wrong for generating dep
using -MM then we should address that issue with Clang specific
compile options. Things like this is why I do not support changing CC from environment variables.

[Alexey Dokuchaev]

It has nothing to do with upholding CC from the environment, or conditional compilation or preprocessing based on CFLAGS. The problem is triggered (or not triggered) by the way different compilers treat system-wide headers.

hardware/r_glide/r_glide.c is Windows-specific, thus #include <windows.h> is not guarded by any macro definition. This file should not have been -MM processed on Unix/Linux at all. Clang strictness here actually exposed the bug in Makefile, while GCC silently generates needless dependency file (as it would not follow system-wide header file like <windows.h>).

The bug is not in Clang or GCC. The bug is in Makefile logic: dependencies for Linux' builds are generated also from the file which can only be compiled/preprocessed in Windows.

[Alexey Dokuchaev]

The bug is still present in 1.45 beta1, relevant lines of the Makefile patch (from the FreeBSD port):

@@ -1002,7 +1002,7 @@ endif
 ../dep/main_t.dep : t*.c
 # none: e*.c j*.c k*.c l*.c n*.c o*.c
 ../dep/hard1.dep : hardware/*.c
-../dep/hard2.dep : hardware/*/*.c
+../dep/hard2.dep : hardware/r_opengl/*.c
 # $(INTERFACE).dep : $(INTERFACE)/*.c
 ../dep/djgppdos.dep : djgppdos/*.c
 ../dep/linux_x.dep : linux_x/*.c linux_x/musserv/*.c linux_x/sndserv/*.c

[Wesley Johnson]

Fixed SVN1135, and is in Release 1.45.2.
The dependency making has been fixed to only include files relevant to the port selection. Smaller dependency files that are more targeted to the port are generated. This eliminates running a compile on a file with missing include, so clang should not have problems now.

The makefile has been changed to allow CLANG as an option, and to accept an environment CC variable (if the CC_ENVIRONMENT var is set). This may not be ideal for clang users, but it leaves the default situation more stable, so user problems can be debugged with some expectation that GCC is the compiler.
Using CC_EXPLICIT also provides a way to override all other CC selection mechanisms, and can also be in make_options.

The source files now have an #ERROR that will trigger if they are used outside their intended port compile.

[Alexey Dokuchaev]

I can confirm that bogus dependency is no longer generated (tested with both Clang and GCC); CC_ENVIRONMENT and CC_EXPLICIT knobs also work as advertised, thank you.