cyclone Once you brought the original issue: "Figure out real dependencies between Zabbix libs, get rid of circular and mutual dependencies":

The idea is to improve organization of Zabbix C code, move functions and files to places they belong to with minimal changes of the code itself.

This will inevitably lead to merge conflicts (of on-going development and between supported versions), so timing and organization is very important.

We are now planning to rewrite Zabbix architecture
It would be great if you could take a look at the following principles :

Pre-mini-spec

Zabbix back-end code consists of the following:
1) binaries code: 1.1) code that compiles directly into an executable binary and is not linked: zabbix_agent, zabbix_get 1.2) private libraries code: code that is compiled into non-executable linkable libraries (.a) and contain logic that is used only by the single binary
2) public libraries code: 'src/libs folder', libraries that are used by other public libraries or binaries
3) public interfaces code: header files in the 'include folder'

I propose to introduce and enforce the following principles

1) The only way for public libraries and binaries code to communicate is through the *public interfaces*
2) The dependencies can be only hierarchical (one-way, circular dependencies are forbidden).

More specifically those principles can be specified as following:

1. There must be strict rules which code goes where

1.1 Code that needs to be shared between a) public library and public library or b) public library and binary -> must go to the public library and have the public interface.
1.2 Code that needs to be shared but only inside the single binary - must go to its binary directory and not have the public interface.
1.3 Code that does not need to be shared - must not reside in a library and must not have a public interface

2. Public interface of the library must contain only the public functions declarations and macros that must be used by other public libraries or binaries .

Everything else must go into library internal directory.

3. Every library must provide only one public interface file.

Header must follow the following naming convention: <name of the library without lib>.h (e.g libzbxmedia.a -> zbxmedia.h). Library must start with "libzbx".

4. There must be no relative include dependencies on public interfaces

5. There must be no global variables that are shared between public libraries and binaries

6. There must be no circular dependencies between libraries

7. Each library must list its set of dependencies in itself

Every library must mention its dependencies in its own Makefile. (currently all dependencies are mentioned during during the linking of the binary in the binary Makefile)
<=>
Every library must be standalone - it must be possible to execute any function from the library by linking only that library and including its header.