Document relative paths in .gdextension files being supported
#11381
Conversation
Calinou
force-pushed
the
gdextension-file-libraries-relative-path
branch
4 times, most recently
from
5ccec64 to
78747d7
Compare
Calinou
added
enhancement
area:manual
There was a problem hiding this comment.
I would prefer to switch the example to use relative names.
We discussed this in GDExtension meetings before, and concluded (iirc) that relative paths are preferable since this supports moving around and renaming the gdextension without having to worry about the .gdextension file. This is also the reason we changed it in the template.
I don't think there are any advantages to using absolute paths, so I'm not sure I'd even mention them.
Calinou
force-pushed
the
gdextension-file-libraries-relative-path
branch
from
78747d7 to
72fcb7b
Compare
Done. |
- Mention support for comments in `.gdextension` files. - List recommended import options for GDExtension icons.
Calinou
force-pushed
the
gdextension-file-libraries-relative-path
branch
from
72fcb7b to
c0ebfbc
Compare
| macos.debug = "bin/libgdexample.macos.template_debug.framework" ; Inline comments are also allowed. | ||
| macos.release = "bin/libgdexample.macos.template_release.framework" |
There was a problem hiding this comment.
In the template, we did all the paths starting with ./, which, if I remember correctly was to fix a MacOS issue? And we also use .dylib in the template and not .framework, which I also remember discussing being to workaround some issue.
Do you folks remember the details?
Anyway, if there was a reason for those changes, we should do them in the docs as well
There was a problem hiding this comment.
Good point! Yea, I believe the macOS load issue is still around, so changing to ./ format would be good.
And yea, the change from framework to dylib also definitely makes sense.
5 participants
.gdextensionfiles.