StevensDeptECE / GrailGUI

GrailGUI is a prototype of a replacement for web programming (HTTP, HTML, CSS, JavaScript) and GUI programming. It includes a client graphical API, a browser implemented in C++ and OpenGL, a protocol to transmit metadata and data in binary, a language (XDL) to describe the binary data, and local storage to retain data on the client should that be necessary. Encrypted communications (equivalent of TLS) have not yet been implemented.
GNU General Public License v3.0
7 stars 14 forks source link

Remove Dependence on the $GRAIL environment variable from Prefs.hh #51

Closed dkrautha closed 3 years ago

dkrautha commented 3 years ago

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:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid
Aborted (core dumped)

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).

dkrautha commented 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.

dkrautha commented 3 years ago

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.

dkrautha commented 3 years ago

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