Good news!
After doing what seemed like banging my head against a wall for hours I managed to produce the compiled exe that creates the tutorial example successfully.
As it turns out, pulling a random compile build off the web and tinkering with it with minimal knowledge was the problem. My non-working build looked like this:
{
"cmd": ["g++", "-o", "${file_path}/${file_base_name}.exe", "-DSFML_STATIC", "-LC:/Coding/mingw32/mingw32/lib", "-IC:/Coding/mingw32/mingw32/include", "-lsfml-graphics", "-lsfml-window", "-lsfml-system", "-static-libgcc", "-static-libstdc++", "${file}"],
"file_regex": "^(..[^:]*):([0-9]+):?([0-9]+)?:? (.*)$",
"working_dir": "${file_path}",
"selector": "source.c, source.cpp, source.c++",
"path": "C:/Coding/mingw32/mingw32/bin",
"shell": true,
"variants": [
{
"name": "Run",
"cmd": ["g++", "-o", "${file_path}/${file_base_name}.exe", "-DSFML_STATIC", "-LC:/Coding/mingw32/mingw32/lib", "-IC:/Coding/mingw32/mingw32/include", "-lsfml-graphics", "-lsfml-window", "-lsfml-system", "-static-libgcc", "-static-libstdc++", "*.cpp", "&", "${file_path}/${file_base_name}.exe"]
}
]
While the above worked just fine for compiling code for a simple and quick console application (indeed that what I was looking for when I found this build on the web) that didn't apparently require any library linking, the order of some of the commands was incorrect.
My new build looks like this(There are a lot of edits here but I will point out the actual important change that allowed this all to work, I think):
{
"cmd": ["g++", "${file}","C:/Coding/MinGW/mingw64/lib/libsfml-graphics.a", "C:/Coding/MinGW/mingw64/lib/libsfml-window.a", "C:/Coding/MinGW/mingw64/lib/libsfml-system.a",
"-o", "${file_path}/${file_base_name}.exe",
"-IC:/Coding/MinGW/mingw64/include",
"-static-libgcc", "-static-libstdc++",],
"file_regex": "^(..[^:]*):([0-9]+):?([0-9]+)?:? (.*)$",
"working_dir": "${file_path}",
"selector": "source.c, source.cpp, source.c++",
"path": "C:/Coding/MinGW/mingw64/bin",
"shell": true,
}
It looks a lot different but I believe most of what occurs when it compiles remains the same
except you'll notice the position of
"${file}" from the "cmd" line has been moved to the front of the command, right after "g++". Also you can see I specified exact pathways to all the libraries directly after that.
I figured this out from reading over the GCC command line documentations (
https://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC6 ) and discovered the process that is supposed to be occuring here;
- the command runs or looks for (im not sure which is more correct) g++
- it then see the source file "${file}"
- then the libraries corresponding to the source file follows
- "-o" is called which specifies to put the
output to "${file_path}/${file_base_name}.exe" (the working directory for the source file)
- Then the preprocessor definitions follow "-I..."
- everything else is as it was after this point ( I removed the "run" variation because I didn't ever use it and it was cluttering)
So ultimately my problem came down to a not comprehending how to interact with the gcc compile commands!
You'll notice also that my MinGW directories have been renamed to "mingw64". I am now using the 64 bit versions of both MinGW and SFML. Everything works as expected.
Now, I've done some experimenting with trying to additionally create a MinGW/SFML build using 32 bit installations. Following exactly the process which led me to finally building and running the tutorial example I was unable to reach the same results. The compiler builds the exe however at runtime a new error occurs:
"The procedure entry point
(gibberish string)
could not be located in the dynamic link library
C:/Coding/MinGW/mingw32/bin/sfml-graphics-2.dll"
Some tinkering with the build has yet to yield anything new. Some searching indicates that using two builds of SFML independently can cause errors like this where MinGW is pointing it resources to the wrong installation, however my assumption was that if i meticulously specified the exact locations of all the libraries and includes in the compiler it would know exactly where to look for everything.
Is this a limitation of what I'm trying to do? I'm running a 64 bit OS but I assumed it wouldn't have trouble compiling 32 bit programs. Could this be more related to how I set up MinGW? Similarly to earlier I've done many checks that my path variables have been set up properly. If it helps, my PATH looks like this:
C:\Users\Charles\scoop\shims;C:\Users\Charles\AppData\Local\Programs\Python\Python35-32\Scripts\;C:\Users\Charles\AppData\Local\Programs\Python\Python35-32\
;C:\Users\Charles\AppData\Local\Programs\Python\Python35\Scripts\;C:\Users\Charles\AppData\Local\Programs\Python\Python35\;
C:\Users\Charles\AppData\Local\Programs\Python\Python35;C:\Python35\Scripts;C:\Python27;C:\Program Files\CMake\bin;C:\Coding\MinGW\mingw32\bin;C:\Coding\MinGW\mingw64\bin;
As I mentioned my assumption was that MinGW would know where to look with all of these specifications, so any input would be appreciated as to why this might be happening.
Nonetheless like I've said I've got the 64bit build set up and running, so yay progress!