Revert "Detect dependency changes in Windows rc compiler"

[jpakkane]

This reverts commit 632115e.

See #15206.

If the issue can't be properly fixed, then sadly the change needs to be taken out.

[bruchar1]

If I understand it correctly:

• 632115e has the side effect that compiler options now affect the behavior of windows.compile_ressources
• Because of that, @lb90 was no longer able to compile glib on Windows (Cannot compile Windows RC file with Meson git #15206).

@bonzini sees it as a bug, and suggest to bypass compiler and global options when processing the ressource file.

But I think this could also be seen as the expected behavior. @lb90 can fix the glib compilation problem simply by adding the proper include directory to the compile_ressources command, as this is already the case with all other targets in glib.

On top of that, I realized that windows.compile_ressources is not adding implicitly the current directory as an include directory (#15215). At first I thought this was the cause of #15206, but it appears to be a different bug.

Therefore, the question is whether or not the project and global options should be used for windows.compile_ressources. Personally, I think that it should, and in that case, #15206 would rather be a glib bug that a meson bug, 632115e should not be reverted, and probably meson documentation could be improved on that point.

[eli-schwartz]

But I think this could also be seen as the expected behavior. @lb90 can fix the glib compilation problem simply by adding the proper include directory to the compile_ressources command, as this is already the case with all other targets in glib.

Then that is a non backwards compatible new feature instead of a bug, but either way it's a regression in existing projects that were obeying the documentation.

Rejected -- if you wish such a new feature it must be opt in, via e.g. a new kwarg defaulting to false. It would then be permissible to plan for changing the default in meson 2.0, in which case you'd need to emit a FeatureDeprecated "compile_resources without explicit xxx kwarg. Currently it defaults to false but in meson 2.0 it will be changed to default to true."

[bruchar1]

Sad, but I guess we have no other choice for now...

[jpakkane]

For the record, when I originally implemented rc compiling, I did not really have a good idea how it is actually used.

• Adding the default libraries to search path should have been done with the same implicit_include_directories kwarg as regular compiles
• As for using project defines, well maybe? It gets tricky when there are many different sources of flags and people might have requirements that only some of them are used. Dunno how common that is in practice, though.

[lb90]

FWIW, Visual Studio's .vcxproj has separate entries for C compiler options and RC compiler options. Namely:

<ClCompile>
  <PreprocessorDefinitions>...</PreprocessorDefinitions>
</ClCompile>
<ResourceCompile>
  <PreprocessorDefinitions>...</PreprocessorDefinitions>
</ResourceCompile>

So if one goes to Properties > C/C++ > Preprocessor > Preprocessor Definitions to add some macro definitions, the changes do not apply to resource compilation. One has to use Properties > Resources > General > Preprocessor Definitions instead.

I think that's done because the RC preprocessor doesn't understand all the command-line options that the CL preprocessor supports: https://devblogs.microsoft.com/oldnewthing/20171004-00/?p=97126. For example, one can pass /wd4668 to cl.exe to disable warning C4668, but rc.exe interprets it as /w: warn on invalid codepage in .rc (default is an error).