freenode/#shirakumo - IRC Chatlog
Search
15:22:47
Colleen
reader.tymoon.eu/article/359 Website (XHTML), Title: Thoughts on Build Systems - Confession 78 - å¦æªä¸æ¨ã¦äºº
16:48:58
Shinmera
eudoxia: gingerale: isoraqathedh: mood: phoe: Would appreciate it if you guys could read this and give me your thoughts. https://reader.tymoon.eu/article/359
16:48:58
Colleen
reader.tymoon.eu/article/359 Website (XHTML), Title: Thoughts on Build Systems - Confession 78 - å¦æªä¸æ¨ã¦äºº
16:50:26
eudoxia
you mentioned allowing a subset of CL as a scripting language, I'd humbly suggesting designing a (well specified) language with its own grammar and semantics. which might be the same as a subset of CL, but I've found it's better to have things explicitly specified than an implicitly described subset-of-a-language, like ParenScript
16:51:06
Shinmera
Yeah, that's one of the things I'm not yet clear on (as anything syntax-y). All I know is that I'd like to keep it non-pure.
16:51:34
Shinmera
Eliminating global side-effects will require a custom evaluator anyway, so I'll probably have to spec my own language no matter what.
16:52:50
Shinmera
The idea being that the objects that "seed" the translation to a plan are always generatable from the project definitions
16:54:55
Shinmera
I don't want to go pure because I expect people (myself included) to hate that too much :^)
16:54:56
eudoxia
have you given any thought at all to dependency resolution or are you considering that as a disjoint problem (to be taken care of by a package manager, not a build system)?
16:55:51
Shinmera
Dependency tracking and resolution is part of the build system (determining which versions to use from where)
16:57:11
Shinmera
I would like to include dependency information outside of Forge itself though, so that something like QL could also interface with other systems to provide those.
16:57:36
eudoxia
so have you decided whether you'd have, arbitrary resolution predicates (<, <=, > any version), or something more restricted?
16:58:32
Shinmera
Probably going to do a thing where versions need to have X.Y.Z format and you can depend on 3.5+,4.6- or whatever.
16:59:11
Shinmera
I'm going to start with the execution engine anyway though, and that's mostly independent from all the other stuff.
16:59:45
Shinmera
Mostly I say, because usually when you define a task you're also going to need to define steps that the task translates to.
17:00:59
Shinmera
Related to that, I'm also not yet sure whether to follow the model of systems like ASDF where you define a "file structure" and then everything operates on that, or whether you'd define a structure for each task, with primitives to inherit structures from other tasks or something like that.
17:02:10
eudoxia
i dont know, I like how ASDF lets you define a total order in which files are compiled: it makes it very easy to follow the program the way the compiler reads it
17:02:34
eudoxia
I certainly prefer that over the mess of runtime `require` and `import` you see in JS and Python
17:04:06
Shinmera
I definitely don't want to immediately strive for some magic shit like Bazel where you just say where the sources are and it "goes," figuring things out on its own somehow.
17:07:01
eudoxia
I have thought of a scheme to probably avoid those problems, though it's probably not applicable in your use case (general build system, not just for code)
17:08:00
eudoxia
needing a general SAT solver for dependency resolution, and the fragility that comes with subtly incompatible (often unnecessary fine-grained) version predicates deep in your dep tree
17:09:13
eudoxia
divide systems into two classes: applications and libraries. libraries can only depend on major versions, applications must specify precise versions of all dependencies, including transitive dependencies. minimize resolution failures as long as semver rules are respected
17:09:38
eudoxia
the total dependency list for applications would be like the `pip freeze` command in the Python ecosystem
17:10:06
eudoxia
an interesting challenge would be statically enforcing semver rules: I think Elm does this
17:15:05
eudoxia
no, but statically you can check the modules are equal in the types, functions etc they export
17:15:32
eudoxia
in CL the best you can do is check the packages export the same symbols, and when those symbols are functions or gfs, check they have the same parameter list
17:15:34
Shinmera
Ah. Not sure it's the responsibility of the build system to do this on its own, but it could be a task, like testing is.
17:16:05
eudoxia
and the package repository would enforce the semver rules when an author tries to upload a new major version
17:16:21
Shinmera
As far as versions are concerned, in my opinion the most the build system should be allowed to constrain is the format so that it can parse it and use it for resolution.
17:23:31
Shinmera
Anyway, I'm sure I'll write another entry when I have a more solid idea of what the dependency / project system is supposed to look like.
17:24:50
Shinmera
In the meantime, if someone writes a miniSAT clone in CL with a very open license, that'd be cool :^)