Developer forums (C::B DEVELOPMENT STRICTLY!) > Contributions to C::B

Code::Blocks Rust integration

<< < (2/2)

sodev:

--- Quote from: Barracuda72 on May 05, 2019, 12:07:28 pm ---just what the hell with all this "package manager - build system - project configuration - etcetcetc" all-in-one goddamn ugly designed thing in modern programming languages?!)

--- End quote ---

Because code sharing and collaboration is a big topic in these environments. A not so big java application of ours uses just about 5 libraries but these pull in about 40 transitive dependencies, you dont want to manage these manually.

Barracuda72:

--- Quote from: oBFusCATed on May 05, 2019, 02:34:25 pm ---Removes opinion, variation and make sharing code to be an easier task, so I think it is a good design decision to have one.

--- End quote ---

No, you are just plain wrong - it's actually _increasing_ opinion and variation. We already have _dozens_ (if not _hundreds_) of package managers and build systems, and the only thing different about them is authors lists and main repo URL. That's just bizzare. Everyone sane would probably choose existing one and contribute to it adjusting existing code to fit their needs... But this tale is not about sanity. Writing cross-platform Makefile even for large-scale multi-language project isn't all that hard (even considering all tips and tricks required for NMake), but today it's considered some kind of forgotten black magick art just because nobody is able to read Make manual. Ehhh, whatever...


--- Quote from: oBFusCATed on May 05, 2019, 02:34:25 pm ---If you look at C/C++ you'll see the other way to do it and we already know it is bad and causes tons of problems. For example good luck using a lib that is using some different build system from yours. It is total PITA. Especially if you have to build it regularly.

--- End quote ---

EXACTLY. And there's one more thing: there shouldn't be mix between package manager and build system. If I want to _use_ library, I should be able to just install it (together with docs and other developer things) and use it. User of my app should be able to install library too (probably without dev stuff) and then use it. We are both not interested in the inner things; we just want the library. Developer (and user all the more so) don't even need to know that build system project uses until they participate in it. As a primarily Gentoo user I'm blessed with Portage that abstracts all this build zoo to simple "emerge that-awesome-lib" (althou sometimes I have to write ebuilds myself, but that's a different story), but same isn't true for billions of humans around the globe who suffer in pain because of some developers' incompetence, and that's more hack than an actual solution.


--- Quote from: sodev on May 05, 2019, 06:48:52 pm ---Because code sharing and collaboration is a big topic in these environments. A not so big java application of ours uses just about 5 libraries but these pull in about 40 transitive dependencies, you dont want to manage these manually.

--- End quote ---

I'm not against collaboration, code sharing, etc, per se - I just hate that instead of using (and maybe extending) existing solutions developers prefer to invent brand-new, unique, their own 100% incompatible wheels.

The point I'm trying to make here is that it would be beneficial for everyone if Rust guys had just picked some well-maintained build system and relied on default system PM to install libraries. But they've chosen their own path... Well, shame on them.

But this disscussion has gone quite off-topic, heh (of course, it's holy war, after all =D). Let's stay close to OP.

oBFusCATed:

--- Quote from: Barracuda72 on May 05, 2019, 07:09:31 pm ---No, you are just plain wrong - it's actually _increasing_ opinion and variation. We already have _dozens_ (if not _hundreds_) of package managers and build systems, and the only thing different about them is authors lists and main repo URL.

--- End quote ---
I'm not sure why you misinterpreted my post. I was talking about cargo. As far as I know there is only one package manager and only one build system for rust. Are there more popular build systems/package managers for rust? I know they try to make it easy to integrate rust in other build systems, but this is different thing.

Barracuda72:

--- Quote from: oBFusCATed on May 05, 2019, 08:02:06 pm ---I'm not sure why you misinterpreted my post. I was talking about cargo. As far as I know there is only one package manager and only one build system for rust. Are there more popular build systems/package managers for rust? I know they try to make it easy to integrate rust in other build systems, but this is different thing.

--- End quote ---
No, I think I didn't make myself clear. I wasn't talking about different PMs for Rust; I grumbled about 1) the fact that instead adopting some existing tools Rust crew desided to roll out their own for no apparent reason and 2) the enourmous problem that every, every tiny language nowadays does the same; at the end of the day we are left with dozens PMs and BSs (cabal, composer, gradle, sbt, pip, npm, go, mvn, nuget, cargo, etcetcetc) that do _exactly_ the same jobs but for different languages and there seems to be no end for this insanity.

Navigation

[0] Message Index

[*] Previous page