Closed Wohlstand closed 10 months ago
Original comment by Pietro Gagliardi (Bitbucket: pgandlabs, ).
Okay I figured out what’s going on: simply having the fallback gme_types.h
in the same directory as the source file that includes it causes gcc and clang (and MSVC too, upon further research) to prioritize that over any gme_types.h
in any of the -I
-specified folders. Here’s a simple reproducer that works on both macOS and Linux:
$ mkdir /tmp/abc; cd /tmp/abc
$ mkdir a b
$ echo '#error a' > a/header.h
$ echo '#error b' > b/header.h
$ echo '#include "header.h"' > a/file.c
$ cc -o /dev/null -I /tmp/abc/b a/file.c
I’m not sure what the best way to fix this is. I can’t find a compiler option to let you move the same-directory search to later in the header file search order, so I’m not sure if this can be fixed cleanly.
The best I can think of: Since it appears the generated gme_types.h isn’t supposed to be installed to the installation prefix, you could possibly alter the cmake build process to define an additional macro to indicate that it generated the file. You would then give both the generated file and the fallback file different filenames, and have gme_types.h
just include the appropriate one based on that macro.
In the meantime, I’ll just delete the fallback gme_types.h
before my local builds.
This is fixed as of commit cdf332f29c719a672920b869680a481a23ade83b
Original report by Pietro Gagliardi (Bitbucket: pgandlabs, ).
Trying to build a subset of game-music-emu as a static library for a personal project, and it appears that all cores are unconditionally included in the final build’s
gme_types_list()
function. Example reproducer:The
gme_types.h
in the cmake build folder has the macros defined correctly, so I’m guessing it’s using thegme_types.h
provided in the repository, which is explicitly marked asI can provide any of the outputs of my run above if needed.
System:
macOS 10.12.6
Xcode 9.2 (9C40b)
cmake version 3.16.4 from MacPorts