On 6/15/2019 2:54 AM, Willy Tarreau wrote:
Actually maybe we should have some super-options separate from the target to decide what feature set to enable. Instead of having just TARGET being mandatory, we could have both TARGET and OPTIONS for example. Then one could just build like this :make TARGET=linux-glibc OPTIONS=all or : make TARGET=freebsd OPTIONS=ssl,zlib,pcre or : make TARGET=cygwin OPTIONS=ssl
Sounds pretty good to me. I do have an idea there, described below.
At this point we'll need to pursue this discussion for 2.1 I guess, and this will not prevent us from backporting some improvements to help users of 2.0. But let's not forget that novices should definitely use their distro's packages first.
The discussion could turn into bikeshedding, but I bet the core team maintains enough authority that somebody can be the benevolent dictator.
The only reason that I build haproxy from source is so that I can run the newest release in whichever X.Y version I'm going for -- distros do lag a bit in that regard, otherwise I would use the distro package. I do use distro packages for most software. Ubuntu doesn't lag as far behind as some of the other distros, and Ubuntu is my preferred flavor right now. At a previous job, I also compiled my own openssl, with static linking, because the load balancer machines were running CentOS 6 and the distro's openssl was ANCIENT.
I'm currently using 1.8, because the bugs I've read about in 1.9 scare me a bit and I'm waiting for it to stabilize. I think I might switch to 1.9 after another release or two ... my interpretation of the grapevine says that the latest releases have worked out most of the problems.
At the moment, here's the only shed colors I have thought of beyond the ideas I've read so far:
* Have OPTIONS=default be possible. MAYBE have that be what the build does if the user doesn't include OPTIONS. With clear documentation in the README about what the default options are, I think an implicit OPTIONS=default could work well.
* Have the build print out what options have been enabled, pause for some reasonably short time period so the user can see it, and then proceed. 5 seconds, maybe up to 10. If there's a sane cross-platform way to do it, provide an option for the user to press some key that skips the pause. The check I mentioned could happen right before that pause point, and if problems are detected, print an error and exit. You'll need to figure out whether or not to add "force" to the options, to go ahead and try a build even when the check detects a problem.
I wish you and the community the best of luck in finding the precise path that's right for haproxy.
Thanks, Shawn
