Open
Conversation
This is the absolute minimum. For Platforms other than Windows, dynamic linking is required as they do not allow dlopen for executables. libraries cannot link against executables either.
cli will now use a static library exporting all its symbols (`gravityapi_sx`) ready for use in plugins
We do not need to export these symbols as we are not linking dynamically anymore.
forgot this line
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Please note: I had to export (or hide) certain symbols:
gravity_json.h(required) these are used mutliple times inside different exposed functions, some even beeing essential.gravity_utils.h(optional and handy) these are really handy for expanding gravity and are simple to understand.gravity_debug.h(optional) for (custom/gravity-specific) editors these symbols will come in handy ~~gravity_compiler.h#gravity_compiler_astI dont think you wanted me to export that much, this would requiregravity_token.handgravity_node.hto be (maybe) mostly exposed to make any sense of it. Subsequently there would be more headers. I chose to hide it, as it is not used anywhere.Regarding
gravity_vm_register_args: I would expose optionals only for the dll (please evaluate this). but for the executable it would not make any sense. besides this is a little less dependent on the optionals. The call does not seem to do anything which requires this specific optional anyway? Maybe it should be moved togravity_vm.h/*.cI added Build-Targets and cleaned up the exports. I also want to add a
dynfolder for the dynamically linkable libraries... currently it looks cluttered.Also: we should export the
computed_property_*/convert_value2*functions. They are really helpful and a headder should either have alle symbols exported or none.SOMETHING needs to be bundled with the executable to make expansion possible. a
*.lib/lib*.ais the absolute minimum. You have to die one death. headers should also be included. however... on windows a dllimport is needed. Thats why I created thegravity_common.hheader. We can choose to put it there. (also it makes exported symbols not include gravity_value...)