-
-
Notifications
You must be signed in to change notification settings - Fork 727
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for Relative Paths #894
Comments
Couldn't we overload the collection system to do this? Like how |
As in Or did you mean we just collect all the paths and add them once and depending how one does do So say for example: foreign import clang "system_app:/lib/libclang" Would still required one to define somehow the system_app path as it doesn't need to be the same every time. E.g “one cannot just simply” for this that path and for that this path with the from you proposed way. |
Hello! I am marking this issue as stale as it has not received any engagement from the community or maintainers 120 days. That does not imply that the issue has no merit! If you feel strongly about this issue
The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.. |
Github bot again.. |
I’ll make a pr with both versions and let’s see what feels better we can certainly add a rpath flag.. |
Bump. |
Well i dang my self taking so long for this.. |
Is your feature request related to a problem? Please describe.
The feature I request is the ability to add rpath's to frameworks and so/lib/dylib files so that the can be relative to some point and are not required to be inside the runtime linker search path.
This is something that is only for Linux and MacOS interesting.
Describe the solution you'd like
My Proposal would be something in that ballpark:
The other option would be to have a relative path search path flag added to the compiler:
odin build main.odin -relative_path="@app/libs/"
I'm not sure which of these two ways is better but one thing that is important is to change the nameingconvention of the relative identifiers as writing out @executable_path and so on is pretty awful.
My proposal in that regard would be to have:
@app = @executable_path (on macOS this actually points to the .app folder)
@bin = @loader_path (this points to the folder containing the actual binary this can be set for libraries and also executables)
Additional context
https://blog.krzyzanowskim.com/2018/12/05/rpath-what/
https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW19
The text was updated successfully, but these errors were encountered: