Closed dkrautha closed 3 years ago
See https://github.com/StevensDeptECE/GrailGUI/commit/1d87a79bc80de581310aa4a2643ccee28b18559c for the start of fixing the first task of this issue.
Right now I'm just using a single header library to get the location of the executable, but ideally I'd start using https://en.cppreference.com/w/cpp/filesystem/path/path in the future.
I started messing with std::filesystem::path
, and it doesn't have the same feature set as cute_path.h
(can't pop something off the end for instance). One massive benefit of what the std library has is that it can concatenate paths in a platform agnostic way, however if we don't get any issues with what we are doing on windows (I haven't tested any of this on windows), then we probably don't need the standard library.
Seems like bundling things in is going to be horrific, so the best bet will be to have a defined project structure for grail projects, and if developers using the library fail to adhere to this it's not our fault
If you don't have the environment variable set, no executable will run as
GLWin
and the shaders class import Prefs.hh, and without the environment variable you'll get the runtime error:The first thing we need to do is remove the dependence on
$GRAIL
entirely, as it makes no sense for users of the final executable to have to have this set.After this it would be cool if we could find a way for the executable to bundle the shader code and any needed assets together so that you could simply run an executable with nothing else required (in the final release builds).