i think pants is the right way to approach this and instead of getting overwhelmed by the right way to integrate spack for c/++ deps i will instead be able to focus entirely on making binaryen less obnoxious to build than with cmake
Post
i think pants is the right way to approach this and instead of getting overwhelmed by the right way to integrate spack for c/++ deps i will instead be able to focus entirely on making binaryen less obnoxious to build than with cmake
i also finally managed to break its caching model with conditionally finding packages or bootstrapping them. and the documentation is really truly among the worst i've literally ever seen in my entire life
i think pants is the right way to approach this and instead of getting overwhelmed by the right way to integrate spack for c/++ deps i will instead be able to focus entirely on making binaryen less obnoxious to build than with cmake
the specific reason i suddenly changed my mind here was because i saw possibly the most horrifyingly inefficient method to embed data into a source file which used cmake. and then i looked up #embed
from jeanheyd and the documentation is great and the comments are going uwu at me on cppreference dot com. and it feels nice you know
now i'm staring at emacs and beginning to whelm over. but i think this would be a better use of my time than debugging cmake which is absolutely no easier to understand after checking out the source code
to be clear i succeeded in fucking around with the terrible build process for binaryen and improving it greatly with a lot of work. but for shit like lto partitioning and the make jobserver the gcc docs are utterly fantastic and that's something i can work with much more readily than the cmake docs
apparently i didn't even get around to opening a pants clone on this box yet. rectifying that now
please. one useable for c.
A space for Bonfire maintainers and contributors to communicate