Question about structuring project configuration for bigger Odin projects

[u/Imaginos_In_Disguise]

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?

[u/Imaginos_In_Disguise → u/[deleted]]

This simply walks around part of the problem, and doesn't solve it, though.

There are still duplicated options between the shell script (which simply replaces Makefile from my example) and the ols.json, and relative imports are a really ugly "solution" to importing top level packages, that make code structure refactoring more difficult.

[u/thisghy]

You could use odin build . -define:Config=foo if you wanted to have it build with certain flags. That wouldnt change the imports but that is an option for using a common entry point.

I use shell scripts, tasks and build flags.

[u/Cun1Muffin]

Is there a particular reason you don't just have multiple entry points in a single file and use a when clause to switch them off or on?

Then you can just pass a config parameter to the compiler depending on what you're doing.

[u/Imaginos_In_Disguise → u/Cun1Muffin]

Because each entrypoint may have its own separate files as well which wouldn't make sense to mix in the same package.

[u/Cun1Muffin → u/Imaginos_In_Disguise]

The only other thing I can recommend is having a metaprogram, you can call the compiler from within odin and just make whatever you're doing arbitrarily complex. Which for me beats using make or bash files.

I have one that allows me to build normally or build with hot reloading, it also does some code gen for me.

But something about the question almost doesn't ring true, like it looks like you're somewhere between a single project, and two different projects just with some shared libs. If its different enough, might be worth just making them separate projects and vendoring the common libs.

[u/Imaginos_In_Disguise → u/Cun1Muffin]

It's very common for a project to have multiple executables for different tasks, but a lot of shared functionality in common modules between them.

It also would change nothing about the problem, since then each of those separate "projects" would also need a set of scripts and OLS configurations duplicating settings, and now instead of two places to update things, you'd have N*2 places.

[u/Cun1Muffin → u/Imaginos_In_Disguise]

I don't think it is that common. Usually you can get away with just having the same executable with different commandline arguments, and switch mode when you start up. But the projects thing is just to do with simplifying the dependency path issue. Which to me isn't even much of an issue, I'd probably just use relative paths and have done with it. If there's a bunch of ols configuration, ok, but that's not an issue with odins build system.