successor to free software which avoids libertarianism and encodes rights https://circumstances.run/@hipsterelectron/112475230792340206
-
@hipsterelectron BTW, I love your build xor pkg concept and it helped me understand that what I’m going for is a build tool and absolutely never a packaging tool, instead leaning on other tools to make that happen.
-
@samir packaging tools are cool as hell too btw!!! and maybe i might accept one that merges both iff it tries REALLY hard to offer divergent interfaces for both of those features. but it seems very difficult to me to do that so i'm just sticking with making them different tools! and packaging protocols over impl-defined is the other really important thing
-
samir, mad idea generatorreplied to d@nny "disc@" mc² last edited by
@hipsterelectron So assuming that you’re correct and it’s better to keep them separate, how do you bind them? Does build call pkg, pkg call build, or a third thing calls both?
I’m leaning towards build calls pkg, but I could be persuaded otherwise.
-
@samir a build system (i prefer "build tool") is a decision made by the individual codebase regarding how to organize their code, and how to compile it into modules (this interacts with the language module facility). as you identified, this will usually involve calling a package manager to obtain dependencies—which the build tool is then able to integrate into the code/module organization
-
@hipsterelectron @samir As a user building FOSS, I *don't want this*. I don't want a tool touching the network at all. I want clear documentation a human can read for what the dependencies are and which let me decide whether to use the ones I have that were packaged by my distro or previously built by me, ir whether to obtain them myself.
-
-
@hipsterelectron @samir I don't think it conflicts, but I'm saying that build tools built for the devs tend to be obstacles in my way as a user who wants to build the sw (maybe with minor changes) myself.
-
P [email protected] shared this topic
