-
Notifications
You must be signed in to change notification settings - Fork 224
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
better cli-rework #412
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I did have an open pull request #374 (after discussion I propably close it).
TL;DR:
LIB
/API
I would like to refine my approach a little. I really like your argument to just ship a single file. In general I would like to embed a
gravity.h
file into gravity which can be exposed with--header
. It would contain all definitions necessary (I am working on it). I would need to make some functions available too and hide others. This is where I would like to differ betweenGRAVITY_API
andGRAVITY_LIB
.LIB
is for using gravity from a dll/so to embed somewhere.API
is to expose to native libraries/modules loaded via imports.Now in a seperate move I would also like to make the cli a little bit more ... common? Currently, any option gets ignored unless its the last (with its parameter). And your executing file is at the end and not after the last option. however most interpreter do not work like this. I would like to change that as well as execute all of the
-i
options, automatically detect serialized files to make-x
obsolete and let-c
be a seperate execution mode. (where-o
would be obsolete). This is already partially done and a pull request ill follow soon.Side question: Would you mind having a specialized binary format for compiled code (not [just] JSON)? I would like it to be as expandable as JSON. A simple TLV encoding might already do the trick.
The text was updated successfully, but these errors were encountered: