Hi guys, On Wed, Jun 12, 2019 at 04:27:42PM +0200, Lukas Tribus wrote: (...) > I think it's a bad idea. > > Basically what Tim says (I was interrupted several times while writing > this email).
OK, and this morning William told me he thought the same for the same reasons, so definitely I'm the one wrong here, which justifies that I asked. And I totally agree with your arguments. (...) > Those will be the interactions, with a lot of round-trips back and > forth. At least the user understands that USE_LUA=1 means that LUA > will be included. With TARGET=ubuntu18 the user may not even know what > LUA is, let alone that it's a dependency. I was actually thinking about enabling what I expect to be installed by default, i.e. zlib & openssl mainly. But at first I didn't want to address libraries as much as the default OS which involves a minimal kernel version and a libc. In the past we've had to guess quite a few times some settings, which were nicely addressed by the split on kernel 2.6.28, but it seems cleaner to support a kernel+libc combination, which is what made me think about distros, hence their respective libs. > So do we brake the build by > default and just document in INSTALL that in Ubuntu 18.04 the LUA > dependency must be fulfilled by installing the source package, which > can be either liblua5.1-0-dev, liblua5.2-dev or liblua5.3-dev? I agree. > INSTALL already contains suggestions about what USE_ flags to include, > as a matter of fact all 5 external libraries mentioned above are > suggested: > > http://git.haproxy.org/?p=haproxy.git;a=blob;f=INSTALL;h=9df17caf68c4f00cdaaaec2ec929f0af66e1d297;hb=HEAD#l35 > > > To be honest, I don't think this is very common in OSS projects; most > of them use configure scripts that just include the library if the > headers are detected, or not link against it at all if it isn't there. > But we would brake the build here, which is different. OK. When discussing this with William, we figured it could be interesting instead to have some aliases which are maybe more symbolic, such as : - linux-complete : full set of supported features, will simply fail if you don't have all libs installed, useful primarily for devs ; - linux-recent : common set of features present by default on latest release of LTS distros at the time of releasing. I.e. could be the default if you have a reasonably up-to-date system ; - linux-ancient : common set of features present by default on oldest supported LTS distros at the time of releasing. Should be a safe fallback for everyone who doesn't want to care more ; - linux-minimal : basically just oldest supported LTS kernel + equivalent libc, would serve as a starting point to manually add USE_*.. In fact I'm still a bit concerned by the fact that we continue to advertise 2.6.28 as the split point while no older kernels are still supported, and that some of the features placed there very likely still don't work well in embedded environments (openwrt for example). I'd like very much to get rid of this laughing "2.6.28" now but if we only use "linux" nobody will update it and we'll be back to the same situation in one or two versions. With the split above we can have fast moving targets ("complete", updated during dev; "recent", updated with new distro announces) and slow moving ones ("ancient", "minimal") and that might be a sweet spot. > > just like we already have for solaris/openbsd/freebsd for example > > None of these include external libraries though, like OpenSSL, LUA, > zlib, PCRE1/2. Only kernel features and "very core" libraries are > included with the solaris/BSD targets (just like linux2628). So the > build may brake because a basic and crucial threading lib is missing, > but not because LUA is not there. That's very different kind of build > failure. Agreed, probably that I was a bit too enthousiast by this idea and conflated several things. We should probably get back to platform and features separately. openssl, lua, zlib, pcre are in fact features if they are not present by default. I was happy to place some of them by default but if they are not necessarily present, let's not force :-) thanks guys for fueling the discussion. Willy
