ignore

Reporter: fundies  |  Status: open  |  Last Modified: July 16, 2020, 10:36:31 PM
codecov[bot]  
>Codecov Report

Merging #2076 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2076      +/-   ##
==========================================
- Coverage   30.95%   30.93%   -0.02%     
==========================================
  Files         197      197              
  Lines       19102    19102              
==========================================
- Hits         5913     5910       -3     
- Misses      13189    13192       +3     
Impacted Files Coverage Δ
ENIGMAsystem/SHELL/Platforms/xlib/XLIBmain.cpp 32.00% <0.00%> (-3.00%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8ecaaa2...092e37a. Read the comment docs.

time-killer-games  

3 things:

  1. I ran into the exact same problem with the compilers on BSD, Robert or somebody needs to fix whatever part of lateralGM and/or the plugin that forces us to rely on the existence of gcc.ey, and not being able to just use clang.ey instead if gcc.ey is not found. Something is screwed up in such a way that you cannot simply make gcc.ey reference clang internally and call it done. It's not that simple because whoever wrote the non-engine parts of the project hardcoded it so that we need gcc.ey to exist AND it actually needs to reference gcc.

  2. due to 1) the temporary fix would be to keep gcc.ey and clang.ey untouched, other than perhaps making clang the default compiler if it isn't already in master. Don't delete or modify either one other earn that, and then this pr will mostly be ready for getting Mac to work again.

  3. lastly, oddly enough, I'm getting a "uname": no such file or directory error at lateralGM startup. Because it couldn't find or launch uname, we ended up with it searching for DLL's instead of having the actual DYLIB extension the DYLIB's we compiled actually have. This can be fixed by adding the full path to uname i.e. shell /usr/bin/uname under Config.mk and voila!

Edit:

gcc and cut are also not being found. not sure why Mac is the only platform with this issue. Anyway that much is solved, and this will probably break FreeBSD since they hold these cli apps under /usr/local/bin/ I believe instead of /usr/bin/ but it's not a huge deal, and I'll take care of that.

GCCVER := $(shell /usr/bin/gcc -dumpversion | /usr/bin/cut -c 1)

OS := $(shell /usr/bin/uname -s)
ifeq ($(OS), Linux)
	LIB_PFX := lib
	LIB_EXT := .so
	BIN_EXT :=
else ifeq ($(OS), Darwin)
	LIB_PFX := lib
	LIB_EXT := .dylib
	BIN_EXT :=
else
	LIB_EXT := .dll
	BIN_EXT := .exe
endif

# Global g++ flags
CXXFLAGS := -std=c++17 -Wall -Wextra -Wpedantic -g -I.
LDFLAGS := -g

# These will be relative to the file that includes this Makefile
SRC_DIR := .
OBJ_DIR := .eobjs

# This implements a recursive wildcard allowing us to iterate in subdirs
rwildcard=$(wildcard $1/$2) $(foreach d,$(wildcard $1/*),$(call rwildcard,$d,$2))

fundies  

gcc is just alias to clang for me. This pr mostly works but theres a segfault in jdi that josh didn't want to help with so its on hold.

That gccver is just an artifact of older travis. I think it can be removed now.

Please sign in to post comments, or you can view this issue on GitHub.