It is a good idea to split compiler and linker flags, but it is not an optimal solution to split them per component (server, proxy, agent, sender, get).
Best solution would be to split CFLAGS per third-party library and take into account specific LIBRARY_CFLAGS only in those Zabbix compilation targets which use the library directly. For example, DB_CFLAGS are specific for libzbxdb.a and TLS_CFLAGS are specific for libzbxcrypto.a. These static libraries should ideally create an abstraction layer for database access and encryption for other parts of Zabbix code. Such approach will minimize the probability of header name conflicts between different third-party libraries (see
ZBX-4069). Including third-party headers as locally as possible will help us to avoid name space pollution (see ZBX-10375).
As to LDFLAGS and LIBS, these are linker flags and therefore can be split per component at best. Splitting LIBS per component is totally fine because we don't want to make any component dependent on shared libraries it will not use in runtime. This also saves a tiny fraction of compilation time.
But per component LDFLAGS and multiple LIBRARY_LDFLAGS can lead to non-obvious results. Using common LDFLAGS for all components and throughout library checking process during ./configure can be a better option.
Consider a situation when two versions of the library are present in the system (see ZBX-4397 and ZBX-8387), for example outdated GnuTLS in /usr/lib (or similar common path) and up-to-date one in /home/user/gnutls. We want Zabbix to use the latter, so:
./configure --enable-agent --enable-server --with-mysql --with-gnutls=/home/user/gnutls
It is very likely that ./configure will find MySQL client library in the same common path where the outdated GnuTLS is installed. It saves -L/usr/lib in DB_LDFLAGS and proceeds with checking GnuTLS library. It finds one in provided path /home/user/gnutls, version is OK, so -L/home/user/gnutls is saved as TLS_LDFLAGS. ./configure succeeds, now make...
Agent binary will be built with specified version of GnuTLS library, because agent does not need DB_LDFLAGS. But linker will fail to link server binary. Linker is provided with DB_LDFLAGS and TLS_LDFLAGS and it will search specified directories for necessary libraries in the order directories were specified. It will find outdated GnuTLS in /usr/lib first.
If the user is advanced enough to know about LD_FLAGS he might try
LD_FLAGS=-L/home/user/gnutls ./configure --enable-agent --enable-server --with-mysql --with-gnutls=/home/user/gnutls
but it will not work either because we use DB_LDFLAGS and TLS_FLAGS as target_LD_FLAGS which have higher priority than ordinary LD_FLAGS. So the server linker gets DB_LDFLAGS then TLS_FLAGS then LD_FLAGS.
The only option left is to export SERVER_LDFLAGS before ./configure but this is really-really-really non-obvious solution and since it is not documented anywhere user will need to investigate configuration process himself.
If we had not split LD_FLAGS per component or per library ./configure would report outdated version of GnuTLS and user could get a hint and use LD_FLAGS to alter directory order for linker.