Hi, On Thu, 9 Mar 2023 at 17:18, Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > > On 09.03.23 15:12, Nazir Bilal Yavuz wrote: > > Hi, > > > > On Thu, 9 Mar 2023 at 16:54, Daniel Gustafsson <dan...@yesql.se> wrote: > >> > >>> On 9 Mar 2023, at 14:45, Peter Eisentraut > >>> <peter.eisentr...@enterprisedb.com> wrote: > >> > >>> How about we just hardcode "openssl" here instead? We could build that > >>> array dynamically, of course, but maybe we leave that until we actually > >>> have a need? > >> > >> At least for 16 keeping it hardcoded is an entirely safe bet so +1 for > >> leaving > >> additional complexity for when needed. > > > > We already have the 'ssl_library' variable. Can't we use that instead > > of hardcoding 'openssl'? e.g: > > > > summary( > > { > > 'ssl': ssl.found() ? [ssl, '(@0@)'.format(ssl_library)] : ssl, > > }, > > section: 'External libraries', > > list_sep: ', ', > > ) > > > > And it will output: > > ssl : YES 3.0.8, (openssl) > > > > I don't think that using 'ssl_library' will increase the complexity. > > Then we might as well use ssl_library as the key, like: > > { > ... > 'selinux': selinux, > ssl_library: ssl, > 'systemd': systemd, > ... > } >
There will be a problem if ssl is not found. It will output 'none: NO' because 'ssl_library' is initialized as 'none' for now. We can initialize 'ssl_library' as 'ssl' but I am not sure that is a good idea. Regards, Nazir Bilal Yavuz Microsoft