When running Gin with a project with modules, one MUST run the command line from the project's directory.
If one tries to run Gin from a different directory, the class is not found during compilation because Gin looks for the class in the module directory starting from the running directory.
For example, ProjectA (/home/user/ProjectA) -> moduleA -> class Foo. If we run Gin from directory /home/user/gin, when looking for class Foo, Gin knows it is from moduleA, so it looks for the class within /home/user/gin/moduleA and it does not find it.
The problem is in this line.
A way to work around it is to get the project directory, concatenate the module dir there, and only then look for the class.
One of the issues here is that TestHarness also uses this method. In order to include the project's dir, we must pass the dir path through the socket or change the process running dir somehow.
When running Gin with a project with modules, one MUST run the command line from the project's directory. If one tries to run Gin from a different directory, the class is not found during compilation because Gin looks for the class in the module directory starting from the running directory.
For example, ProjectA (
/home/user/ProjectA) -> moduleA -> class Foo. If we run Gin from directory/home/user/gin, when looking for class Foo, Gin knows it is from moduleA, so it looks for the class within/home/user/gin/moduleAand it does not find it.The problem is in this line. A way to work around it is to get the project directory, concatenate the module dir there, and only then look for the class.
One of the issues here is that TestHarness also uses this method. In order to include the project's dir, we must pass the dir path through the socket or change the process running dir somehow.