#curl's configure script has 75(!) different --disable options to disable specific things in the build.
That's 37778931862957161709568 build combinations only there. Tricky to test.
⇧
#curl's configure script has 75(!) different --disable options to disable specific things in the build.
That's 37778931862957161709568 build combinations only there. Tricky to test.
Kevin Lyda
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Kevin Lyda • • •Kevin Lyda
in reply to daniel:// stenberg:// • • •You maintain a 5,000+ line configure.ac file? Holy fuck. You poor man.
Folks, please help this guy get the therapy he needs:
opencollective.com/curl
#curl #ptsd #torment
curl - Open Collective
opencollective.comdaniel:// stenberg://
in reply to Kevin Lyda • • •@lyda 5K is nothing 🤠
it is actually north of 17,000 lines counting all the individual additional .m4 files as well!
Kevin Lyda
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Kevin Lyda • • •@lyda it has been said that the 4 in m4 is the total amount of people understanding it, and I'm not one of them.
But I get by good enough pretending I know it. That's typically enough to survive and to write decently working configure stuff.
Petr Tesarik
in reply to daniel:// stenberg:// • • •Daniel P. Berrangé 📷 🎨 🔭 📡
in reply to daniel:// stenberg:// • • •@lyda its practically an unwinnable war for non-trivial software
Each option always sounds reasonable in isolation when someone first proposes it. Even if you could retrospectively cull 20% of the build flags, the combinatorial expansion will still dwarf the number of scenarios it is practical to regularly test.
And yet this problem seems to mostly affect the C/C++ world. In other languages (perl,python, rust, go, etc) language specific build tools don't typically offer end users anywhere near the same level of fine granularity in build/deployment choices that people expect (demand) from C/C++ apps.
Has autoconf's design (inadvertently) pushed projects in an undesirable direction, and/or set unreasonable expectations for users in terms of granularity of build time choices ?
daniel:// stenberg://
in reply to Daniel P. Berrangé 📷 🎨 🔭 📡 • • •Sven A. Schmidt
in reply to daniel:// stenberg:// • • •Daniel Janus
in reply to daniel:// stenberg:// • • •An idea would be to randomly sample, say, 100 combinations out of that space using something like Vitter’s Method D [0], and test those.
I’ve been experimenting with this approach in my Clojure library [1].
[0]: ittc.ku.edu/~jsv/Papers/Vit87.…
[1]: github.com/nathell/cartestian
GitHub - nathell/cartestian: Test all the combinations
GitHubdaniel:// stenberg://
in reply to Daniel Janus • • •Ian Lewis
in reply to daniel:// stenberg:// • • •journey
in reply to daniel:// stenberg:// • • •Fish Id Wardrobe
in reply to daniel:// stenberg:// • • •vsz
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to vsz • • •vsz
in reply to daniel:// stenberg:// • • •Alien software, human hardware
in reply to daniel:// stenberg:// • • •Maybe it's time for "vibe testing"?
awb
in reply to daniel:// stenberg:// • • •Klaus Frank
in reply to daniel:// stenberg:// • • •Ngl, that's one of the main reasons I hate C/C++ projects. It is basically impossible to just change one line or two to test something without first spending at least a week or two getting into all of the project despite already knowing which line of code you actually want to change.
Followed by not having any kind of dependency management...