Hello Willy,
On Wed, 12 Jun 2019 at 07:39, Willy Tarreau <[email protected]> wrote: > > Hi all, > > I'm currently re-reading my notes for the upcoming release and found > something I noted not that long ago regarding the TARGET variable of > the makefile. The list of operating systems hasn't changed in a while > and in parallel we've added a bunch of build options that do not solely > depend on the kernel anymore, but more on features related to the whole > environment (pcre, openssl, lua, systemd, zlib, and so on). > > I thought that now that the targets definition is very simple in the > makefile, we could simply add distro names and versions and adjust the > set of default USE_xxx variables based on this. We could thus have > rhel{8,7,6,5}, debian{9,8,7,6}, ubuntu{18,16}, fedora{31,30,29} and so > on, just like we already have for solaris/openbsd/freebsd for example, > except that we generally only reference one version there. It would > become easier to add new variants even to stable distros to ease the > build for new users, who would just have to issue "make TARGET=debian9" > for example, without having to figure if PCRE2 has to be specified or > OPENSSL or any such thing. > > This this is fairly minor and basically just requires a few lines to > be added to the makefile and to the doc, so I'm fine with including > this to the final release. > > So my questions are : > - does anybody think it's a bad idea ? I think it's a bad idea. Basically what Tim says (I was interrupted several times while writing this email). For the build not to fail, all those libraries *and the source package of it* have to be installed first. Even if (I imagine) some of those libraries in some of the OS configurations are installed by default, the source packages with the header files are still missing and the build would fail for every single dependency by default, which are at least 5 (PCRE and variants, OpenSSL, LUA, ZLIB, SYSTEMD). By not requiring the user to think about the libraries, we are hiding complexity, which will then come up on the mailing list, discourse and github issues. "my build fails with a libssl.h error" --> install libssl-dev "now the build still fails, but with a libz.h error" --> install libz-dev "now the build still fails, but with a systemd.h error" --> install systemd-dev libraries 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. 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? 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. > 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. cheers, lukas
