end to end test with conan support

[luoliwoshang]

libxml2 difference

In the Linux (apt) version, in addition to the pointer declaration difference, there's an extra definition of the _uconv_t structure and its type alias:
apt install libxml2-dev libxml/encoding.h

    /*
    * Block defining the handlers for non UTF-8 encodings.
    * If iconv is supported, there are two extra fields.
    */
    #ifdef LIBXML_ICU_ENABLED
    /* Size of pivot buffer, same as icu/source/common/ucnv.cpp CHUNK_SIZE */
    #define ICU_PIVOT_BUF_SIZE 1024
    struct _uconv_t {
    UConverter *uconv; /* for conversion between an encoding and UTF-16 */
    UConverter *utf8; /* for conversion between UTF-8 and UTF-16 */
    UChar      pivot_buf[ICU_PIVOT_BUF_SIZE];
    UChar      *pivot_source;
    UChar      *pivot_target;
    };
    typedef struct _uconv_t uconv_t;
    #endif

typedef struct _xmlCharEncodingHandler xmlCharEncodingHandler;
typedef xmlCharEncodingHandler *xmlCharEncodingHandlerPtr;
struct _xmlCharEncodingHandler {
    char                       *name;
    xmlCharEncodingInputFunc   input;
    xmlCharEncodingOutputFunc  output;
#ifdef LIBXML_ICONV_ENABLED
    iconv_t                    iconv_in;
    iconv_t                    iconv_out;
#endif /* LIBXML_ICONV_ENABLED */
#ifdef LIBXML_ICU_ENABLED
    uconv_t                    *uconv_in;
    uconv_t                    *uconv_out;
#endif /* LIBXML_ICU_ENABLED */
};

In contrast, the macOS (brew) version only retains a forward declaration of the structure, without the complete structure definition and type alias.

/*
 * Block defining the handlers for non UTF-8 encodings.
 * If iconv is supported, there are two extra fields.
 */
typedef struct _xmlCharEncodingHandler xmlCharEncodingHandler;
typedef xmlCharEncodingHandler *xmlCharEncodingHandlerPtr;
struct _xmlCharEncodingHandler {
    char *name;
    xmlCharEncodingInputFunc input;
    xmlCharEncodingOutputFunc output;
#ifdef LIBXML_ICONV_ENABLED
    iconv_t iconv_in;
    iconv_t iconv_out;
#endif /* LIBXML_ICONV_ENABLED */
#ifdef LIBXML_ICU_ENABLED
    struct _uconv_t *uconv_in;
    struct _uconv_t *uconv_out;
#endif /* LIBXML_ICU_ENABLED */
};

[luoliwoshang]

for lua5.4,need config different c toolchain

[luoliwoshang]

Currently, we might be able to directly use llpkgstore https://github.com/goplus/llpkgstore for more complete end-to-end comparative testing. By storing llpkg.cfg and llcppg.cfg in the test cases, comparative tests can be run after each CI execution to ensure that updates meet expectations.

@MeteorsLiu what's your view ?

[MeteorsLiu]

Which subcommands in llpkgstore will be used for debugging?

[luoliwoshang]

Which subcommands in llpkgstore will be used for debugging?

llpkgstore generate,and in expect test folder ,there will have llpkg.cfg & llcppg.cfg to config the generate operation.

[MeteorsLiu]

For test cases in llcppg, it dones't require llpkg.cfg actually. So my question is that should we usellpkgstore generate? Because it requires llpkg.cfg.

[luoliwoshang]

in my view , maybe only see it is a construct tool for test ? but i think your concern is correct,it's not nessary to use llpkg.cfg,it will hard depend llpkgstore.

[MeteorsLiu]

We can call Upstream.Installer directly, which is a wrapper for installing packages using conan.

[luoliwoshang]

sound's good, if we direct use the llpkgstore generate,we may have a senario like llcppg change the result output,the llpkgstore generate can't apply this case to check new result.

[luoliwoshang]

maybe we can complete these test function to https://github.com/goplus/llcppg/tree/main/cmd/llcppgtest. and for a test we also need a config file to specify version of c package, what about

the name、version、options is all from conan.
installpkg.json

{
      "name": "cjson",
      "version": "1.7.18",
      "options": "",
}

[MeteorsLiu]

In that case, why we don't use llpkg.cfg?

[luoliwoshang]

yeah,in the test case will llpkg.cfg also lead some misunderstanding like depend llpkg,it will only be a independent test logic.

[MeteorsLiu]

I don't think we have to create a kind of special format config file, BTW, here's the definition of llpkg:

An llpkg is a Go module that invokes libraries of other languages through LLGo's ecosystem integration capability.

In conclusion, Go modules that are compiled by llgo can be recognized as llpkg.

[luoliwoshang]

llcppg shouldn't introduce llpkg.cfg solely to reuse llpkgstore's Conan installation logic. If we later opt to duplicate this logic directly, then llpkg.cfg would be even more redundant.