Skip to main content


#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
in reply to daniel:// stenberg://

Might that be a reason to reduce their number? To make the build more reasonable to test?
in reply to Kevin Lyda

@lyda it's the constant battle and balance: providing the features and options people ask for and at the same time maintain quality and testability. So sure, I think every option should be questioned from that angle.
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:

https://opencollective.com/curl

#curl #ptsd #torment

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!

in reply to daniel:// stenberg://

At this point do you actually understand m4? I admined sendmail back in the day and did a number of much smaller autoconf scripts for other projects back when I coded in C. But never really *got* m4.
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.

in reply to daniel:// stenberg://

@lyda Oh no, and I hoped someone would finally explain dnl and changequote to me. Or at least the difference between [something] and [[something]].
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]: https://www.ittc.ku.edu/~jsv/Papers/Vit87.RandomSampling.pdf

[1]: https://github.com/nathell/cartestian

in reply to Daniel Janus

@nathell I actually started out this morning writing a script that runs configure with a random collection of the 75 disable options. It revealed a lot already.
in reply to daniel:// stenberg://

If each test took a nanosecond to run, it would only take 1,197,962 years!
Unknown parent

daniel:// stenberg://
@berrange @lyda I don't think autoconf pushes for more options than anything else. It's just that these become build time options, not run-time as you would in many other places. Being able to switch off things at build time reduces attack surfaces that run-time checks cannot.
in reply to daniel:// stenberg://

that's … frightening. how do you decide which combinations to test? you don't have to answer
in reply to daniel:// stenberg://

if we bring CMake to the party, it also has 61 enable/disable + 30 dependency flags. That's 91 bits of combinations right there. Throw in some more with platform, compiler and compiler versions that all trigger a slightly different compilation path.
This entry was edited (1 month ago)
in reply to vsz

@vsz most of these combo problems are in the source code though, independent of cmake vs autotools
@vsz
in reply to daniel:// stenberg://

Indeed. It me made thinking to do a translation table between configure and cmake options to spot remaining differences.
This entry was edited (1 month ago)
in reply to daniel:// stenberg://

This problem is what Combinatorial Interaction Testing is looking to address. This 2013 IEEE Computer article on testing the 1.8×10^55 combinations of the Apache config is a good description of that approach (https://doi.org/10.1109/MC.2013.408).
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...