Comment by izzylan
3 months ago
I don't see the value in making it even harder to build software. I want to make things. Downloading a dependency manually and then cursing at the compiler because "it's right there! why won't it load!!" is just gonna make me want to build software less.
Anyone I want to work with on a project is going to have to have the same frustration and want to work on the project less. Only even more because you see they downloaded version 2.7.3-2 but the version I use is 2.7.3-1.
> Downloading a dependency manually and then cursing at the compiler because "it's right there! why won't it load!!"
Odin's compiler knows what a package is and will compile it into your program automatically.
Isn't that a (built-in) package manager if it works for general packages? Or does it work only for selected dependencies?
From what I've seen. The Odin has three package collections: `base`, `core` and `vendor`.
`base` is intrinsically necessary to port Odin. `core` seems to be its standard library, your `libc`, `xml`, etc.
And `vendor` is everything else. So you basically get the Python's '`core` is where packages go to die' approach iff they take backwards compatibility seriously. Otherwise, they have breaking changes mid-language version change.
EDIT: Package collections not packages per gingerBill.
9 replies →
It doesn't necessarily "manage" the packages. It just sees them in your project and compiles them. You manage them yourself.
8 replies →
This is an argument for a good build system, not a package manager.
These aren’t always separate.
Some distos might try to support multiple versions of a library. That could require installing it to different prefixes instead of the default. Thus, the build system will have to comprehend that.
Not everything in the world revolves around Linux. Distros terrible choices around shared library architecture has nothing to do with build systems for most languages.
3 replies →
Build systems are yet another special circle of hell.