Question about structuring project configuration for bigger Odin projects
Hey,
I've been generally enjoying Odin for small projects, but there's a struggle I've been having as soon as the project hits the point where structure is needed.
This problem is usually solved in other languages via conventional project structures implemented by standard centralized build systems, which Odin avoids.
Example: If I have a project with multiple entrypoints that also have common logic they need to be able to import, something like this project structure:
├── bin
│ ├── entrypoint1
│ │ └── main.odin # import "local:common"
│ └── entrypoint2
│ └── main.odin # import "local:common"
├── local
│ └── common
│ └── common.odin
For this structure to work, however, I need to always call odin like odin run bin/entrypoint1 -collection:local=./local as a CLI option.
In order for it to persist as project configuration, I need to create a Makefile duplicating every odin sub-command that takes that option.
This is also required if I need any other non-default compiler option passed in.
For it to also work with OLS, I need to create a ols.json file and repeat configuration mirroring the same compiler options there as well, so there's no longer a single source of truth describing the project's flags, and if this ever changes or I need to add more collections (like vendored dependencies), there are now two places to update.
How are you dealing with this issue in your projects?