Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve makefile experience for Mingw and MacOS #1241

Closed
DanRStevens opened this issue Feb 21, 2025 · 0 comments · Fixed by #1278
Closed

Improve makefile experience for Mingw and MacOS #1241

DanRStevens opened this issue Feb 21, 2025 · 0 comments · Fixed by #1278

Comments

@DanRStevens
Copy link
Collaborator

DanRStevens commented Feb 21, 2025

The CI builds need custom variables set in the environment for Mingw and MacOS builds. Maybe we can incorporate more support directly into the makefile.

Mingw:

    WARN_EXTRA: "-Wno-redundant-decls"
    LDFLAGS_EXTRA: "-L/usr/local/x86_64-w64-mingw32/lib"

MacOS:

    echo "export CPLUS_INCLUDE_PATH=${CPLUS_INCLUDE_PATH}:$(brew --prefix)/include" >> "${BASH_ENV}"
    echo "export LDFLAGS_EXTRA=-L$(brew --prefix)/lib" >> "${BASH_ENV}"

Additionally, for the OPHD Mingw build, the WARN_EXTRA flag also includes -Wno-dangling-reference. Though that's also used for the GCC build, and seems to be tied to a new warning flag that may be a bit buggy.


The makefile has a TARGET_OS variable, which when set to Windows could be an indication that we expect to use the Mingw specific libraries for linking. I don't know of a good way to query for an appropriate library search path. Potentially we could scan the output of sdl2-config --libs for just the -L flag. Or we could assume it's in some standard location, such as is used by the Dockerfile. Currently the Dockerfile sets the path using a basic install prefix combined with a target architecture component:

  • ARCH64=x86_64-w64-mingw32
  • ARCH32=i686-w64-mingw32
  • INSTALL_PREFIX=/usr/local/
  • INSTALL64=${INSTALL_PREFIX}${ARCH64}/
  • INSTALL32=${INSTALL_PREFIX}${ARCH32}/

Edit: It is possible to use a Mingw specific version of pkg-config to find the needed folder.

sudo apt install mingw-w64-tools
x86_64-w64-mingw32-pkg-config --libs-only-L sdl2

-L/usr/local/x86_64-w64-mingw32/lib

This matches with the path constructed above.


Edit 2:
A bug was discovered with the pkg-config file for the SDL2_image library, which was reported and quickly fixed:
libsdl-org/SDL_image#527 (comment)


Edit 3:
An update to use the Mingw version of pkg-config can result in harmless warnings when the tool is not installed and TARGET_OS is set to Windows:

make: x86_64-w64-mingw32-pkg-config: No such file or directory
make: x86_64-w64-mingw32-pkg-config: No such file or directory

This can be handled the same way the warning was removed for the sdl2-config tool when it wasn't found.

SDL_CONFIG := sdl2-config
SDL_CONFIG_CFLAGS := $(shell type $(SDL_CONFIG) >/dev/null 2>&1 && $(SDL_CONFIG) --cflags)
SDL_CONFIG_LIBS := $(shell type $(SDL_CONFIG) >/dev/null 2>&1 && $(SDL_CONFIG) --libs)

Edit 4:

It seems the Mingw version of pkg-config also has issues with the glew library:

x86_64-w64-mingw32-pkg-config --libs glew

Package glu was not found in the pkg-config search path.
Perhaps you should add the directory containing `glu.pc'
to the PKG_CONFIG_PATH environment variable
Package 'glu', required by 'glew', not found

The preprocessor flag -DGLEW_STATIC is used to disable the need for a glu library install. Hence that dependency is optional. Perhaps that package configuration file could be updated to reflect the optional nature of the dependency. Currently it's not possible to use pkg-config for the glew package without the glu dependency also installed.

Guide to pkg-config:
https://people.freedesktop.org/~dbn/pkg-config-guide.html


The makefile has a CURRENT_OS variable, which when set to Darwin could be an indication that we expect to use brew for dependencies. That could enable us to set flags for the include search path and library search path to add the brew specific folders.


Related:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant