-
-
Notifications
You must be signed in to change notification settings - Fork 570
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
core:build
draft
#2958
base: master
Are you sure you want to change the base?
core:build
draft
#2958
Conversation
…oved parse_args. Added Settings.custom_args and optional allow_custom_args bool in settings_init_from_args. Added a custom default context that initializes a console logger. Added logging in favor of eprintf error handling. Needs review
…for easier replacement
…om_args. When the flag is builtin and custom, a warning will be logged and the builtin behavior will be skipped
…s rework in other places. Removed the need for build.add_project for now, hopefully it stays like this
…ng build systems from each other
… Target.name. Rewriting procs to use Targets instead of Configs
… automatic absolute path from build.odin in favor of setting them in user code.
… path to it. Finished up examples
… example is in place
…cuting build.run_target inside another Target.target_proc
…ake their build system in other subdirectories. This allows it to be run like `odin run subdir/..../build`.
Flag_Arg :: struct { // -flag:key=val | ||
flag: string, | ||
key: string, | ||
val: string, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One issue with Odin's flag argument style is that it doesn't really allow for pipe-line passing, or general shell expansion.
I chose this approach in Odin purely because it was as simple and consistent, even if it has its issues. It's also the reason why I have never written a flag library for Odin because which approach do you choose?--given that each approach has its flaws.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you can "choose" an approach for a flag library if it needs to be in core
, as every approach is so fundamentally different from each other (unix style allowing multiple single letter flags under a single -
(-rf
or -r -f
).
My thoughts on that is that you can provide styles (.Odin .Unix .Windows
), and do different things based on the style of flags the app supports. For example, core:build
would use the core:argument_parser
or whatever with the .Odin
style.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd have some ideas for this in order to make the "setup" cross-style compatible, i might give it a shot eventually when i get some extra time
{.Dev, {"-ols", "", ""}, "Generates an ols.json for the configuration."}, | ||
{.Dev, {"-vscode", "", ""}, "Generates .vscode folder for debugging."}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically ols
is unofficial, so having part of an official tool is kind of "weird". Same with the -vscode
thing. Yes both are very useful, but I am not sure if those should be here or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah i understand that. The flags you pass to your build system can be expanded by yourself, so the builtin flags like -ols
and -vscode
are things that the user would write themselves anyway, so why not provide them as "sensible defaults". Generally speaking, all .Dev
flags are meant for "non-official" dev tools, like setting up your debugger, your language server, anything you need to make your development easier. Personally i think this approach is more useful than it's weird, and I'd like to keep expanding on the .Dev
flags for other editors and tools that people use (and can be used in a "generic" way like configuring a json). The usefulness itself also comes from the way core:build
in it's current version works, as you are able to configure your dev env specifically for a certain target
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so I've been thinking about this. The tools to generate 3rd party things is quite useful, but indeed there is a bit of "weirdness" into it. I do think the feature itself should stay, as it makes core:build
more useful than a python/bat/sh script, so here are some things that I could experiment with if you end up not agreeing with 3rd party being in core
:
- Make a
vendor:build/dev
package, or alternatively different packages for each 3rd party toolvendor:build/vscode
vendor:build/ols
. These can handle setting up default development environments that we support "officially" via thevendor
packages. Asvendor
is already supposed to contain 3rd party things, this solution would make the most sense. - Create a system to "register" dev environments, something like
build.add_dev("vscode", flags_that_trigger_vscode_gen, vscode_gen_proc)
. This could also work well with the addition of optionalvendor:build
already made dev environments.
My biggest gripe with any of these solutions is that ultimately I wanted core:build
to be a single self contained package, in order to allow importing build systems into eachother, a feature which is very useful when you want to build multiple projects as a single one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while you think about it, I'll try to handle flags a bit better, and at least separate the third party things better, and we'll see what we do with them. Right now all the .Dev
flags are bound to 3rd party generation, so probably the best way to separate them for now is to make the .Dev
mode triggered only by a -dev
flag
Some points discussed with @gingerBill in our talk a few weeks ago + some points that should still be discussed regarding this. If i remember correctly, the best approach currently is to leave this be for now and make it a separate project for people to play around with + maybe a poll/github-discussion to figure out whether or not people actually find something like this useful. Compiler supportCompiler can help with running the build script. odin build build # on linux, running with -out:build so that we don't have to spell out "build.out"
./build dbg -vscode -ols # generate the vscode debug settings and ols.json for target "dbg". This command can be separated into 2 calls
./build dbg # actually build the target How would this look with the
Furthermore, compiler support can also give us a reason to have something like Third party tools support is useful, but also weird.Flags like Integration with
|
This is a repost of #2874 . I moved it to a different branch rather than
DragosPopse/Odin:main
in order to be able to revert to the original odin version and start work on other things. Sorry for the duplicate, will try to be more careful next time.Copy-paste of last important message
I have finalized the API. Things might still need extra testing, but so far it seems to work.
example build script:
output of
odin run build
:output of
odin run build -- -help
:output of
odin run build -- -ols -vscode
ols.json
:.vscode/launch.json
:.vscode/tasks.json
:Concept explanation
The idea of
core:build
would be to provide an api for running complex odin builds + a CLI to help you decide what you want to run. ATarget
is what it's being run by the cli or viabuild.run_target
. This can be anything fromdebug/release
targets toinstall
orclean
. These are setup by the user. In order to run a target, you need to create it, add it withbuild.add_target
to aProject
(a collection of targets), and either callbuild.run_target
in code orodin run build -- <target name>
via the CLIRun_Mode
is the mode the CLI runs in. It can be one of{.Build, .Dev, .Help}
. The mode defaults toBuild
unless certain flags make it a different mode (runningodin run build -- -ols
sets the mode to.Dev
).The
Run_Mode
allows to user to determine what they want to do when the target is being ran..Build
would be the general build mode, where they can callbuild.odin
, copy dlls, etc..Dev
is used for configuring development enviornment (generatingols.json
, information for the debugger they use. As a builtin debugger example, VSCode is implemented, but more can be added in future PRs, and the user can configure their own development environment..Help
is for displaying information about your target to the user of the CLI. The current PR doesn't have abuild.default_help
proc. It's planned for later.In order to facilitate importing build systems into eachother, the
build.*path(target, path)
functions make sure that your paths are relative to the build system. I have experimenting with ensuring that automatically on the library-side, but it seemed less "magical" this way (even if it still is a tiny bit). Internally, this system uses#caller_location
when callingbuild.add_target
in order to setTarget.root_dir
todir(#caller_location)/../
. This effectively means that the build system will always need to be built from the parent folder that it's in (odin build build
as opposed toodin build .
). This is the strangest part of this system, but it's going to make a lot of sense for dependency handling (being able to run imported targets like thisodin run build -- project2/debug
from the "main" build system.Additional Features
odin run build -- *
map
s and[dynamic]
arrays, but those will be removed in later PRs.Testing for yourself
Open a command line in ODIN_ROOT/examples/package_build
run
odin run build
to build the project, orodin run build -- -help
to display available optionsFinal notes
The
(WIP)
flags are still left to be implemented. The system of setting up custom flag is nearly in place, but i'm still thinking if it's supposed to be "general flags" or "per target" flags. There still needs to be an advanced example written where dependencies are being handled and including build systems into eachother.If the API is good, I'd like to have this PR merged before doing other updates, as I'd like to open a clean PR for further improvements. I want to start clean on the git side, with a custom branch on my own fork where i can keep working on other things.
Future PRs (if this is accepted)
Future dream
core:build
can be expanded to handle more than odin code. With the dependency handling, users could do something likeimport vendor:glfw/build
and include the build system forglfw
into their own, calling it's targets. This can be helpful for a lot ofvendor
libraries.vendor:glfw/build
could be as simple as calling thebuild.bat
on windows, butcore:build
can be expanded to be able to configure flags for C and CMake projects too.