We currently have the following limitations with our registration files (in the following just referenced as gdj files) which we introduced with #441:
gdj files need to be inside the godot project folder - > the main problem here is that this currently is an implicit requirement
gdj files are mapped to the actual class files via relative path from the gdj root directory -> can lead to problems on case insensitive file systems when directories (aka packages) are cased differently in code and on the file system
gdj files can not be moved by the user, only the gdj root dir can be changed
These problems can be divided into two different improvements (which all tie together. Hence they are mentioned here):
Tie gdj file name to class instead of relative path
The gdj file name is actually already unique. Even for libraries and when fqName registration is enabled. Hence we can completely ditch the mapping by relative path and map directly by registration file name.
From godot we still get the request to resolve a script by resource path like: res://scripts/subdir/MyClass.gdj but MyClass is already unique as far as gdj's are concerned. Hence we can just take the substring after the last / and use that as the identifier to retrieve the correct class.
Update gdj files by file tree scan rather than gdj root dir replacement
Note: This requires the above improvement to work.
During build we generate the new registration files, update existing ones and delete obsolete ones. This is currently done "automatically" by ksp for us. But only inside the build dir.
After ksp is done, we copy it to the users defined gdj root dir. This we can change so we scan the project dir for gdj files and create, update and delete them accordingly.
This would allow the user to freely move the gdj files to where he wants them to be (or leave them where they are by default).
We currently have the following limitations with our registration files (in the following just referenced as
gdjfiles) which we introduced with #441:gdjfiles need to be inside the godot project folder - > the main problem here is that this currently is an implicit requirementgdjfiles are mapped to the actual class files via relative path from the gdj root directory -> can lead to problems on case insensitive file systems when directories (aka packages) are cased differently in code and on the file systemgdjfiles can not be moved by the user, only the gdj root dir can be changedThese problems can be divided into two different improvements (which all tie together. Hence they are mentioned here):
Tie
gdjfile name to class instead of relative pathThe
gdjfile name is actually already unique. Even for libraries and when fqName registration is enabled. Hence we can completely ditch the mapping by relative path and map directly by registration file name. From godot we still get the request to resolve a script by resource path like:res://scripts/subdir/MyClass.gdjbutMyClassis already unique as far asgdj's are concerned. Hence we can just take the substring after the last/and use that as the identifier to retrieve the correct class.Update
gdjfiles by file tree scan rather than gdj root dir replacementNote: This requires the above improvement to work. During build we generate the new registration files, update existing ones and delete obsolete ones. This is currently done "automatically" by ksp for us. But only inside the build dir. After ksp is done, we copy it to the users defined gdj root dir. This we can change so we scan the project dir for
gdjfiles and create, update and delete them accordingly. This would allow the user to freely move the gdj files to where he wants them to be (or leave them where they are by default).