2023-01-02 21:00:37 +01:00
|
|
|
# Copyright (c) 2022-2023, PostgreSQL Global Development Group
|
2022-12-20 13:54:39 +01:00
|
|
|
|
meson: Add initial version of meson based build system
Autoconf is showing its age, fewer and fewer contributors know how to wrangle
it. Recursive make has a lot of hard to resolve dependency issues and slow
incremental rebuilds. Our home-grown MSVC build system is hard to maintain for
developers not using Windows and runs tests serially. While these and other
issues could individually be addressed with incremental improvements, together
they seem best addressed by moving to a more modern build system.
After evaluating different build system choices, we chose to use meson, to a
good degree based on the adoption by other open source projects.
We decided that it's more realistic to commit a relatively early version of
the new build system and mature it in tree.
This commit adds an initial version of a meson based build system. It supports
building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD,
Solaris and Windows (however only gcc is supported on aix, solaris). For
Windows/MSVC postgres can now be built with ninja (faster, particularly for
incremental builds) and msbuild (supporting the visual studio GUI, but
building slower).
Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM
bitcode generation, documentation adjustments) are done in subsequent commits
requiring further review. Other aspects (e.g. not installing test-only
extensions) are not yet addressed.
When building on Windows with msbuild, builds are slower when using a visual
studio version older than 2019, because those versions do not support
MultiToolTask, required by meson for intra-target parallelism.
The plan is to remove the MSVC specific build system in src/tools/msvc soon
after reaching feature parity. However, we're not planning to remove the
autoconf/make build system in the near future. Likely we're going to keep at
least the parts required for PGXS to keep working around until all supported
versions build with meson.
Some initial help for postgres developers is at
https://wiki.postgresql.org/wiki/Meson
With contributions from Thomas Munro, John Naylor, Stone Tickle and others.
Author: Andres Freund <andres@anarazel.de>
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Peter Eisentraut <peter@eisentraut.org>
Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
2022-09-22 06:53:12 +02:00
|
|
|
pgport_sources = [
|
|
|
|
'bsearch_arg.c',
|
|
|
|
'chklocale.c',
|
|
|
|
'inet_net_ntop.c',
|
|
|
|
'noblock.c',
|
|
|
|
'path.c',
|
|
|
|
'pg_bitutils.c',
|
|
|
|
'pg_strong_random.c',
|
|
|
|
'pgcheckdir.c',
|
|
|
|
'pgmkdirp.c',
|
|
|
|
'pgsleep.c',
|
|
|
|
'pgstrcasecmp.c',
|
|
|
|
'pgstrsignal.c',
|
|
|
|
'pqsignal.c',
|
|
|
|
'qsort.c',
|
|
|
|
'qsort_arg.c',
|
|
|
|
'quotes.c',
|
|
|
|
'snprintf.c',
|
|
|
|
'strerror.c',
|
|
|
|
'tar.c',
|
|
|
|
'thread.c',
|
|
|
|
]
|
|
|
|
|
|
|
|
if host_system == 'windows'
|
|
|
|
pgport_sources += files(
|
|
|
|
'dirmod.c',
|
|
|
|
'kill.c',
|
|
|
|
'open.c',
|
|
|
|
'system.c',
|
Fix detection of unseekable files for fseek() and ftello() with MSVC
Calling fseek() or ftello() on a handle to a non-seeking device such as
a pipe or a communications device is not supported. Unfortunately,
MSVC's flavor of these routines, _fseeki64() and _ftelli64(), do not
return an error when given a pipe as handle. Some of the logic of
pg_dump and restore relies on these routines to check if a handle is
seekable, causing failures when passing the contents of pg_dump to
pg_restore through a pipe, for example.
This commit introduces wrappers for fseeko() and ftello() on MSVC so as
any callers are able to properly detect the cases of non-seekable
handles. This relies mainly on GetFileType(), sharing a bit of code
with the MSVC port for fstat(). The code in charge of getting a file
type is refactored into a new file called win32common.c, shared by
win32stat.c and the new win32fseek.c. It includes the MSVC ports for
fseeko() and ftello().
Like 765f5df, this is backpatched down to 14, where the fstat()
implementation for MSVC is able to understand about files larger than
4GB in size. Using a TAP test for that is proving to be tricky as
IPC::Run handles the pipes by itself, still I have been able to check
the fix manually.
Reported-by: Daniel Watzinger
Author: Juan José Santamaría Flecha, Michael Paquier
Discussion: https://postgr.es/m/CAC+AXB26a4EmxM2suXxPpJaGrqAdxracd7hskLg-zxtPB50h7A@mail.gmail.com
Backpatch-through: 14
2023-04-12 02:09:38 +02:00
|
|
|
'win32common.c',
|
meson: Add initial version of meson based build system
Autoconf is showing its age, fewer and fewer contributors know how to wrangle
it. Recursive make has a lot of hard to resolve dependency issues and slow
incremental rebuilds. Our home-grown MSVC build system is hard to maintain for
developers not using Windows and runs tests serially. While these and other
issues could individually be addressed with incremental improvements, together
they seem best addressed by moving to a more modern build system.
After evaluating different build system choices, we chose to use meson, to a
good degree based on the adoption by other open source projects.
We decided that it's more realistic to commit a relatively early version of
the new build system and mature it in tree.
This commit adds an initial version of a meson based build system. It supports
building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD,
Solaris and Windows (however only gcc is supported on aix, solaris). For
Windows/MSVC postgres can now be built with ninja (faster, particularly for
incremental builds) and msbuild (supporting the visual studio GUI, but
building slower).
Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM
bitcode generation, documentation adjustments) are done in subsequent commits
requiring further review. Other aspects (e.g. not installing test-only
extensions) are not yet addressed.
When building on Windows with msbuild, builds are slower when using a visual
studio version older than 2019, because those versions do not support
MultiToolTask, required by meson for intra-target parallelism.
The plan is to remove the MSVC specific build system in src/tools/msvc soon
after reaching feature parity. However, we're not planning to remove the
autoconf/make build system in the near future. Likely we're going to keep at
least the parts required for PGXS to keep working around until all supported
versions build with meson.
Some initial help for postgres developers is at
https://wiki.postgresql.org/wiki/Meson
With contributions from Thomas Munro, John Naylor, Stone Tickle and others.
Author: Andres Freund <andres@anarazel.de>
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Peter Eisentraut <peter@eisentraut.org>
Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
2022-09-22 06:53:12 +02:00
|
|
|
'win32dlopen.c',
|
|
|
|
'win32env.c',
|
|
|
|
'win32error.c',
|
|
|
|
'win32fdatasync.c',
|
Fix detection of unseekable files for fseek() and ftello() with MSVC
Calling fseek() or ftello() on a handle to a non-seeking device such as
a pipe or a communications device is not supported. Unfortunately,
MSVC's flavor of these routines, _fseeki64() and _ftelli64(), do not
return an error when given a pipe as handle. Some of the logic of
pg_dump and restore relies on these routines to check if a handle is
seekable, causing failures when passing the contents of pg_dump to
pg_restore through a pipe, for example.
This commit introduces wrappers for fseeko() and ftello() on MSVC so as
any callers are able to properly detect the cases of non-seekable
handles. This relies mainly on GetFileType(), sharing a bit of code
with the MSVC port for fstat(). The code in charge of getting a file
type is refactored into a new file called win32common.c, shared by
win32stat.c and the new win32fseek.c. It includes the MSVC ports for
fseeko() and ftello().
Like 765f5df, this is backpatched down to 14, where the fstat()
implementation for MSVC is able to understand about files larger than
4GB in size. Using a TAP test for that is proving to be tricky as
IPC::Run handles the pipes by itself, still I have been able to check
the fix manually.
Reported-by: Daniel Watzinger
Author: Juan José Santamaría Flecha, Michael Paquier
Discussion: https://postgr.es/m/CAC+AXB26a4EmxM2suXxPpJaGrqAdxracd7hskLg-zxtPB50h7A@mail.gmail.com
Backpatch-through: 14
2023-04-12 02:09:38 +02:00
|
|
|
'win32fseek.c',
|
meson: Add initial version of meson based build system
Autoconf is showing its age, fewer and fewer contributors know how to wrangle
it. Recursive make has a lot of hard to resolve dependency issues and slow
incremental rebuilds. Our home-grown MSVC build system is hard to maintain for
developers not using Windows and runs tests serially. While these and other
issues could individually be addressed with incremental improvements, together
they seem best addressed by moving to a more modern build system.
After evaluating different build system choices, we chose to use meson, to a
good degree based on the adoption by other open source projects.
We decided that it's more realistic to commit a relatively early version of
the new build system and mature it in tree.
This commit adds an initial version of a meson based build system. It supports
building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD,
Solaris and Windows (however only gcc is supported on aix, solaris). For
Windows/MSVC postgres can now be built with ninja (faster, particularly for
incremental builds) and msbuild (supporting the visual studio GUI, but
building slower).
Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM
bitcode generation, documentation adjustments) are done in subsequent commits
requiring further review. Other aspects (e.g. not installing test-only
extensions) are not yet addressed.
When building on Windows with msbuild, builds are slower when using a visual
studio version older than 2019, because those versions do not support
MultiToolTask, required by meson for intra-target parallelism.
The plan is to remove the MSVC specific build system in src/tools/msvc soon
after reaching feature parity. However, we're not planning to remove the
autoconf/make build system in the near future. Likely we're going to keep at
least the parts required for PGXS to keep working around until all supported
versions build with meson.
Some initial help for postgres developers is at
https://wiki.postgresql.org/wiki/Meson
With contributions from Thomas Munro, John Naylor, Stone Tickle and others.
Author: Andres Freund <andres@anarazel.de>
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Peter Eisentraut <peter@eisentraut.org>
Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
2022-09-22 06:53:12 +02:00
|
|
|
'win32getrusage.c',
|
|
|
|
'win32link.c',
|
|
|
|
'win32ntdll.c',
|
|
|
|
'win32pread.c',
|
|
|
|
'win32pwrite.c',
|
|
|
|
'win32security.c',
|
|
|
|
'win32setlocale.c',
|
|
|
|
'win32stat.c',
|
|
|
|
)
|
2022-12-06 20:25:54 +01:00
|
|
|
elif host_system == 'cygwin'
|
|
|
|
pgport_sources += files(
|
|
|
|
'dirmod.c',
|
|
|
|
)
|
meson: Add initial version of meson based build system
Autoconf is showing its age, fewer and fewer contributors know how to wrangle
it. Recursive make has a lot of hard to resolve dependency issues and slow
incremental rebuilds. Our home-grown MSVC build system is hard to maintain for
developers not using Windows and runs tests serially. While these and other
issues could individually be addressed with incremental improvements, together
they seem best addressed by moving to a more modern build system.
After evaluating different build system choices, we chose to use meson, to a
good degree based on the adoption by other open source projects.
We decided that it's more realistic to commit a relatively early version of
the new build system and mature it in tree.
This commit adds an initial version of a meson based build system. It supports
building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD,
Solaris and Windows (however only gcc is supported on aix, solaris). For
Windows/MSVC postgres can now be built with ninja (faster, particularly for
incremental builds) and msbuild (supporting the visual studio GUI, but
building slower).
Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM
bitcode generation, documentation adjustments) are done in subsequent commits
requiring further review. Other aspects (e.g. not installing test-only
extensions) are not yet addressed.
When building on Windows with msbuild, builds are slower when using a visual
studio version older than 2019, because those versions do not support
MultiToolTask, required by meson for intra-target parallelism.
The plan is to remove the MSVC specific build system in src/tools/msvc soon
after reaching feature parity. However, we're not planning to remove the
autoconf/make build system in the near future. Likely we're going to keep at
least the parts required for PGXS to keep working around until all supported
versions build with meson.
Some initial help for postgres developers is at
https://wiki.postgresql.org/wiki/Meson
With contributions from Thomas Munro, John Naylor, Stone Tickle and others.
Author: Andres Freund <andres@anarazel.de>
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Peter Eisentraut <peter@eisentraut.org>
Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
2022-09-22 06:53:12 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
if cc.get_id() == 'msvc'
|
|
|
|
pgport_sources += files(
|
|
|
|
'dirent.c',
|
|
|
|
'win32gettimeofday.c',
|
|
|
|
)
|
|
|
|
endif
|
|
|
|
|
|
|
|
# Replacement functionality to be built if corresponding configure symbol
|
|
|
|
# is false
|
|
|
|
replace_funcs_neg = [
|
|
|
|
['explicit_bzero'],
|
|
|
|
['getopt'],
|
|
|
|
['getopt_long'],
|
|
|
|
['getpeereid'],
|
|
|
|
['inet_aton'],
|
|
|
|
['mkdtemp'],
|
|
|
|
['preadv', 'HAVE_DECL_PREADV'],
|
|
|
|
['pwritev', 'HAVE_DECL_PWRITEV'],
|
|
|
|
['strlcat'],
|
|
|
|
['strlcpy'],
|
|
|
|
['strnlen'],
|
|
|
|
]
|
|
|
|
|
|
|
|
if host_system != 'windows'
|
|
|
|
replace_funcs_neg += [['pthread_barrier_wait']]
|
|
|
|
endif
|
|
|
|
|
|
|
|
# Replacement functionality to be built if corresponding configure symbol
|
|
|
|
# is true
|
|
|
|
replace_funcs_pos = [
|
|
|
|
# x86/x64
|
|
|
|
['pg_crc32c_sse42', 'USE_SSE42_CRC32C'],
|
|
|
|
['pg_crc32c_sse42', 'USE_SSE42_CRC32C_WITH_RUNTIME_CHECK', 'crc'],
|
|
|
|
['pg_crc32c_sse42_choose', 'USE_SSE42_CRC32C_WITH_RUNTIME_CHECK'],
|
|
|
|
['pg_crc32c_sb8', 'USE_SSE42_CRC32C_WITH_RUNTIME_CHECK'],
|
|
|
|
|
|
|
|
# arm / aarch64
|
|
|
|
['pg_crc32c_armv8', 'USE_ARMV8_CRC32C'],
|
|
|
|
['pg_crc32c_armv8', 'USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 'crc'],
|
|
|
|
['pg_crc32c_armv8_choose', 'USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK'],
|
|
|
|
['pg_crc32c_sb8', 'USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK'],
|
|
|
|
|
|
|
|
# generic fallback
|
|
|
|
['pg_crc32c_sb8', 'USE_SLICING_BY_8_CRC32C'],
|
|
|
|
]
|
|
|
|
|
|
|
|
pgport_cflags = {'crc': cflags_crc}
|
|
|
|
pgport_sources_cflags = {'crc': []}
|
|
|
|
|
|
|
|
foreach f : replace_funcs_neg
|
|
|
|
func = f.get(0)
|
|
|
|
varname = f.get(1, 'HAVE_@0@'.format(func.to_upper()))
|
|
|
|
filename = '@0@.c'.format(func)
|
|
|
|
|
|
|
|
val = '@0@'.format(cdata.get(varname, 'false'))
|
|
|
|
if val == 'false' or val == '0'
|
|
|
|
pgport_sources += files(filename)
|
|
|
|
endif
|
|
|
|
endforeach
|
|
|
|
|
|
|
|
foreach f : replace_funcs_pos
|
|
|
|
func = f.get(0)
|
|
|
|
varname = f.get(1, 'HAVE_@0@'.format(func.to_upper()))
|
|
|
|
filename = '@0@.c'.format(func)
|
|
|
|
|
|
|
|
val = '@0@'.format(cdata.get(varname, 'false'))
|
|
|
|
if val == 'true' or val == '1'
|
|
|
|
src = files(filename)
|
|
|
|
if f.length() > 2
|
|
|
|
pgport_sources_cflags += {f[2]: pgport_sources_cflags[f[2]] + src}
|
|
|
|
else
|
|
|
|
pgport_sources += src
|
|
|
|
endif
|
|
|
|
endif
|
|
|
|
endforeach
|
|
|
|
|
|
|
|
|
|
|
|
if (host_system == 'windows' or host_system == 'cygwin') and \
|
|
|
|
(cc.get_id() != 'msvc' or cc.version().version_compare('<14.0'))
|
|
|
|
|
|
|
|
# Cygwin and (apparently, based on test results) Mingw both
|
|
|
|
# have a broken strtof(), so substitute its implementation.
|
|
|
|
# That's not a perfect fix, since it doesn't avoid double-rounding,
|
|
|
|
# but we have no better options.
|
|
|
|
pgport_sources += files('strtof.c')
|
|
|
|
message('On @0@ with compiler @1@ @2@ we will use our strtof wrapper.'.format(
|
|
|
|
host_system, cc.get_id(), cc.version()))
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Build pgport once for backend, once for use in frontend binaries, and once
|
|
|
|
# for use in shared libraries
|
|
|
|
pgport = {}
|
|
|
|
pgport_variants = {
|
|
|
|
'_srv': internal_lib_args + {
|
|
|
|
'dependencies': [backend_port_code],
|
|
|
|
},
|
|
|
|
'': default_lib_args + {
|
|
|
|
'dependencies': [frontend_port_code],
|
|
|
|
},
|
|
|
|
'_shlib': default_lib_args + {
|
|
|
|
'pic': true,
|
|
|
|
'dependencies': [frontend_port_code],
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach name, opts : pgport_variants
|
|
|
|
|
|
|
|
# Build internal static libraries for sets of files that need to be built
|
|
|
|
# with different cflags
|
|
|
|
cflag_libs = []
|
|
|
|
foreach cflagname, sources : pgport_sources_cflags
|
|
|
|
if sources.length() == 0
|
|
|
|
continue
|
|
|
|
endif
|
|
|
|
c_args = opts.get('c_args', []) + pgport_cflags[cflagname]
|
|
|
|
cflag_libs += static_library('libpgport@0@_@1@'.format(name, cflagname),
|
|
|
|
sources,
|
2022-10-07 02:19:30 +02:00
|
|
|
c_pch: pch_c_h,
|
meson: Add initial version of meson based build system
Autoconf is showing its age, fewer and fewer contributors know how to wrangle
it. Recursive make has a lot of hard to resolve dependency issues and slow
incremental rebuilds. Our home-grown MSVC build system is hard to maintain for
developers not using Windows and runs tests serially. While these and other
issues could individually be addressed with incremental improvements, together
they seem best addressed by moving to a more modern build system.
After evaluating different build system choices, we chose to use meson, to a
good degree based on the adoption by other open source projects.
We decided that it's more realistic to commit a relatively early version of
the new build system and mature it in tree.
This commit adds an initial version of a meson based build system. It supports
building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD,
Solaris and Windows (however only gcc is supported on aix, solaris). For
Windows/MSVC postgres can now be built with ninja (faster, particularly for
incremental builds) and msbuild (supporting the visual studio GUI, but
building slower).
Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM
bitcode generation, documentation adjustments) are done in subsequent commits
requiring further review. Other aspects (e.g. not installing test-only
extensions) are not yet addressed.
When building on Windows with msbuild, builds are slower when using a visual
studio version older than 2019, because those versions do not support
MultiToolTask, required by meson for intra-target parallelism.
The plan is to remove the MSVC specific build system in src/tools/msvc soon
after reaching feature parity. However, we're not planning to remove the
autoconf/make build system in the near future. Likely we're going to keep at
least the parts required for PGXS to keep working around until all supported
versions build with meson.
Some initial help for postgres developers is at
https://wiki.postgresql.org/wiki/Meson
With contributions from Thomas Munro, John Naylor, Stone Tickle and others.
Author: Andres Freund <andres@anarazel.de>
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Peter Eisentraut <peter@eisentraut.org>
Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
2022-09-22 06:53:12 +02:00
|
|
|
kwargs: opts + {
|
|
|
|
'c_args': c_args,
|
|
|
|
'build_by_default': false,
|
|
|
|
'install': false,
|
|
|
|
},
|
|
|
|
)
|
|
|
|
endforeach
|
|
|
|
|
|
|
|
lib = static_library('libpgport@0@'.format(name),
|
|
|
|
pgport_sources,
|
|
|
|
link_with: cflag_libs,
|
2022-10-07 02:19:30 +02:00
|
|
|
c_pch: pch_c_h,
|
meson: Add initial version of meson based build system
Autoconf is showing its age, fewer and fewer contributors know how to wrangle
it. Recursive make has a lot of hard to resolve dependency issues and slow
incremental rebuilds. Our home-grown MSVC build system is hard to maintain for
developers not using Windows and runs tests serially. While these and other
issues could individually be addressed with incremental improvements, together
they seem best addressed by moving to a more modern build system.
After evaluating different build system choices, we chose to use meson, to a
good degree based on the adoption by other open source projects.
We decided that it's more realistic to commit a relatively early version of
the new build system and mature it in tree.
This commit adds an initial version of a meson based build system. It supports
building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD,
Solaris and Windows (however only gcc is supported on aix, solaris). For
Windows/MSVC postgres can now be built with ninja (faster, particularly for
incremental builds) and msbuild (supporting the visual studio GUI, but
building slower).
Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM
bitcode generation, documentation adjustments) are done in subsequent commits
requiring further review. Other aspects (e.g. not installing test-only
extensions) are not yet addressed.
When building on Windows with msbuild, builds are slower when using a visual
studio version older than 2019, because those versions do not support
MultiToolTask, required by meson for intra-target parallelism.
The plan is to remove the MSVC specific build system in src/tools/msvc soon
after reaching feature parity. However, we're not planning to remove the
autoconf/make build system in the near future. Likely we're going to keep at
least the parts required for PGXS to keep working around until all supported
versions build with meson.
Some initial help for postgres developers is at
https://wiki.postgresql.org/wiki/Meson
With contributions from Thomas Munro, John Naylor, Stone Tickle and others.
Author: Andres Freund <andres@anarazel.de>
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Peter Eisentraut <peter@eisentraut.org>
Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
2022-09-22 06:53:12 +02:00
|
|
|
kwargs: opts + {
|
|
|
|
'dependencies': opts['dependencies'] + [ssl],
|
|
|
|
}
|
|
|
|
)
|
|
|
|
pgport += {name: lib}
|
|
|
|
endforeach
|
|
|
|
|
|
|
|
pgport_srv = pgport['_srv']
|
|
|
|
pgport_static = pgport['']
|
|
|
|
pgport_shlib = pgport['_shlib']
|