cross platform & refactor deps design

design.md

@@ -19,7 +19,9 @@ If `config-file` is not specified, a `llcppg.cfg` file is used in current direct
   ],
   "libs": "$(pkg-config --libs inireader)",
   "trimPrefixes": ["Ini", "INI"],
-  "cplusplus":true
+  "cplusplus":true,
+  "deps":["C","github.com/..../third"],
+  "root":true 
 }
 ```
 
@@ -83,3 +85,133 @@ It fetches information of C/C++ symbols and print to stdout. Its format is as fo
 gogensig ast-file
 gogensig -  # read AST from stdin
 ```
+
+
+## Dependencies Management (Deps)
+
+### Third-party Dependencies and Standard Library References
+* All third-party dependencies and standard library references must be explicitly declared in Deps.
+* For example, if `libxslt` depends on `libxml2` and `zlib`, these dependencies must be declared in llcppg.cfg:
+* For third-party dependencies and standard library references, they must be declared in Deps.
+
+```json
+{
+  "include": [
+    "libxslt/xslt.h",
+    "libxslt/security.h",
+    "libexslt/exsltconfig.h"
+  ],
+  "deps": [
+    "C",
+    "github.com/goplus/..../xml2",
+    "github.com/goplus/..../zlib"
+  ]
+}
+```
+### Header File Processing Rules
+
+- llcppg will not convert header files that don't belong to the current package (including third-party packages and standard libraries).
+- For types that the converted package depends on, llcppg will search for type mappings within the current package.
+- If a mapping type is found, it will be referenced; otherwise, llcppg will notify the user about missing types and their source header files for conversion.
+
+For example, `libxslt/xsltutils.h` depends on `xmlChar` and `xmlNodePtr` from `libxml2` :
+
+`libxslt/xsltutils.h`
+```c
+#include <libxml/dict.h>
+#include <libxml/xmlerror.h>
+#include <libxml/xpath.h>
+xmlChar * xsltGetNsProp(xmlNodePtr node, const xmlChar *name, const xmlChar *nameSpace);
+```
+
+If mappings for xmlChar and xmlNodePtr are not found, llcppg will notify the user about these missing types and indicate they are from libxml2 header files.
+
+### Header File Ownership Determination
+
+#### Package Header Files
+- Header files declared in include are considered as interface header files of the current package.
+- Header files located in the same root directory as the include files are considered as implementation header files of the current package.
+For example, paths obtained through Clang and library linking in the above example:
+```
+/opt/homebrew/Cellar/libxslt/1.1.42_1/include/libxslt/xslt.h
+/opt/homebrew/Cellar/libxslt/1.1.42_1/include/libxslt/security.h
+/opt/homebrew/Cellar/libxslt/1.1.42_1/include/libexslt/exsltconfig.h
+```
+The calculated common root directory is:
+
+```bash
+/opt/homebrew/Cellar/libxslt/1.1.42_1/include/
+```
+
+In `libxslt/xslt.h`, the following header files are referenced:
+```c
+#include <libxml/tree.h>
+#include "xsltexports.h"
+```
+The corresponding paths are: `libxml/tree.h` -> `/opt/homebrew/Cellar/libxml2/2.13.5/include/libxml2/libxml/tree.h` (third-party dependency)
+
+`xsltexports.h` -> `/opt/homebrew/Cellar/libxslt/1.1.42_1/include/libxslt/xsltexports.h` (package implementation file)
+
+Since `xsltexports.h` is in the same directory as `libxslt/xslt.h` , it is considered as a current package implementation file, and its content is generated in `xslt_autogen.go` . While `libxml/tree.h` is not in the same directory, it is considered as a third-party dependency.
+
+#### System Path Header File Processing
+- In Linux, libraries installed through apt might have third-party library headers located in the same directory as system headers (e.g., `/usr/include/sqlite3.h` and `/usr/include/stdio.h` ).
+- For such cases, you can configure `Root: false` in `llcppg.cfg` to indicate that the current conversion project is not in a separate package conversion project.
+- Under this configuration, all files declared in include are the header files that need to be converted in the current conversion project. Header files not declared in the package are considered non-package header files, their conversion is ignored, and their types are declared and loaded through Deps.
+
+
+## Cross-Platform File Content Handling
+
+For header files that behave differently across platforms, configuration is managed through `impl.files`. For these files, platform-specific build constraints will be generated during content generation. For example, in the following project, `t1.h` and `t2.h` have platform-specific variations:
+
+```json
+{
+    "impl": [
+        {
+            "files": [
+                "t1.h",
+                "t2.h"
+            ],
+            "cond": {
+                "os": [
+                    "macos",
+                    "linux"
+                ],
+                "arch": [
+                    "arm64",
+                    "amd64"
+                ]
+            }
+        }
+    ]
+}
+```
+The generated `t1.go` & `t2.go` files will include platform-specific build constraints at the beginning of each file:
+
+For macOS ARM64:
+```go
+// +build macos,arm64
+
+package xxx
+```
+For Linux ARM64:
+```go
+// +build linux,arm64
+
+package xxx
+```
+For macOS AMD64:
+
+```go
+// +build macos,amd64
+
+package xxx
+```
+
+For Linux AMD64:
+
+```go
+// +build linux,amd64
+
+package xxx
+```