How can one create a shared package?

Explain
1

I have my own math and types that need to be shared across packages, and the only way I can find to do that is by using:

import "../Math"
import "../Types"

with the double dots. I don’t like having relative imports, but I’ll use them like this and keep going. Maybe the solution is creating my own collection, but I have no idea how to do that. If it can’t be done, it doesn’t matter… It’s just an aesthetic thing.

1 Like
2

You can create a custom collection but the easiest way would be to put the folder in “shared” subfolder of the odin install directory, right next to the core and vendor subfolders.

2 Likes
3

I personally view this as a perceived aesthetic problem and not a real one in practice. And any collection you make will be longer to type too and add another flag to your build script.

And judging from your packages, they sound like a really bad idea too. Why are the “Types” not part the package that uses them directly? It seems like a completely unneeded “organization” which will be painful for you, if not now already, in the future.

Packages are meant to be libraries, not ways to “organize/taxonomize” your code.

4 Likes
4

The reason is that I was following Handmade hero day 470 tutorial in odin and I reached a point where Casey abstracts a renderer Layer, In the renderer layer he imported the game types and math into the renderer. Actually, I dont know if it is a good idea.

5

I’d keep them all the same package. There is no reason to separate them out to different libraries which won’t be reused anywhere, especially in the case of Handmade Hero.

1 Like
6

You’re right, I dont plant to reuse it so I will follow your advice and unabstract it into a single package and keep going, it amazed me that it literally took less than 5 minutes to unabstract and it compiles and runs. Thanks!

image
image196×143 3.94 KB

7

This is something that I’m also not a big fan of. Refactors do often involve moving around directories and having to fix it around everywhere kind of sucks.

I’m a bigger fan of the whole ‘namespace’ thing with how C# does it.

Anyway, the collections thing is a good enough workaround. you can use -collection:namespace:abs_path/to/dir_with_multiple/packages in your compile command to rewire it to work better than how it is right now.

For a more practical example, instead of doing something like import "../Engine/AssetManagement" or import "../../../Engine/AssetManagement", I prefer to handle it via -collection:Engine=src/Engine flag, and using imports everywhere as import "Engine:AssetManagement". This way, I don’t have to worry about how deep in the dir structure the current package is, relative to the imported one.

1 Like
8

So the problem here is that from the exact examples you have given me, it sounds like the reason you “need” to move around directors and such is because you had those in the first place. C# and other such languages are very “hierarchical” with their package structure which is something I want to completely avoid in the first place.

I am not saying don’t use collections but in the case of the original thing, people over use packages when they should just place a more in a single directory and stop trying to add artificial taxonomies/hierarchies.

2 Likes