add a tool for generate .pub file

[tsingbx]

No description provided.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.27%. Comparing base (d483b13) to head (9f5d097).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1008   +/-   ##
=======================================
  Coverage   89.27%   89.27%           
=======================================
  Files          27       27           
  Lines        6958     6958           
=======================================
  Hits         6212     6212           
  Misses        708      708           
  Partials       38       38           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[luoliwoshang]

llcppg.pub file stores mappings from original C names to public Go names, not mappings from Go's typedef underlying types to typedef names"

llgo/c/c.go

Lines 39 to 41 in 9edaa8e

	type FILE struct {
	Unused [8]byte
	}

llgo/c/c.go

Lines 58 to 65 in 9edaa8e

	type SizeT = uintptr
	type IntptrT = uintptr
	type UintptrT = uintptr
	type Int8T = int8
	type Int16T = int16
	type Int32T = int32
	type Int64T = int64

For example, it would map something like:

llcppg.pub

FILE
size_t SizeT
intptr_t IntptrT
int8_t Int8T
int16_t Int16T
int32_t Int32T
int64_t Int64T

The left side shows the original type names in C language, while the right side shows the corresponding Go names after conversion. By reading this mapping, we can know what public Go name corresponds to each original C name.

When the C name and Go name are identical，like FILE,only the C name is listed - no need for a second column

[tsingbx]

以后添加新类型必须写上c原始映射类型到注释，这个工作量太大。

type Int8T = int8 //cname:int8_t

[luoliwoshang]

对于llgo编译器来说，是否引入这个标识是仍然需要讨论的。

//cname:int8_t

[tsingbx]

也可以不加，但是那样的话需要做添加类型后，在c标准库的llcppg.pub上添加。添加//cname:注释可以提高代码可读性。

[tsingbx]

如果添加上又2个好处，提高可读性和方便自动生成.pub文件。

[luoliwoshang]

认同可以增加可读性，这里这个设计也就是会期望一个转换完成的Go包，会存在一个内含类型映射描述的Go文件，同时为了llcppg读取还会再存在一个llcppg.pub文件么。

如果是这样，那么在一个包中再存放额外一份映射信息会有一定的冗余。

[tsingbx]

目前就是这样设计。独立一个pub文件是为了方便处理，为了独立性。否则处理导入的时候，要读取每个.go文件。

[luoliwoshang]

目前就是这样设计。独立一个pub文件是为了方便处理，为了独立性。否则处理导入的时候，要读取每个.go文件。

@xushiwei 是否需要引入这个设计还是需要对齐一下的，这对于llgo来说会是新的规则，这里我认为存在两个相同的映射信息在同一个包中会存在冗余。

[tsingbx]

目前就是这样设计。独立一个pub文件是为了方便处理，为了独立性。否则处理导入的时候，要读取每个.go文件。

@xushiwei 是否需要引入这个设计还是需要对齐一下的，这对于llgo来说会是新的规则，这里我认为存在两个相同的映射信息在同一个包中会存在冗余。

有些事情是不需要讨论的。如果卡的太死，就没有创新了。

[luoliwoshang]

For the third-party library llcppg.pub, it will be automatically generated by llcppg

[luoliwoshang]

Therefore, we should not, nor can we, implement an automated tool to extract the original C source names to Go names into llcppg.pub from this converted Go file. (We cannot obtain the original C type names from this Go file, nor can we determine which types in the current Go file have corresponding types in the C language.)

[luoliwoshang]

This mapping table from C source names to Go names should be 'llcppg.pub', not 'pkgname.pub',like this c.pub

[tsingbx]

最后会合并，然后删除临时的pub

[luoliwoshang]

Therefore, we should not, nor can we, implement an automated tool to extract the original C source names to Go names into llcppg.pub from this converted Go file. (We cannot obtain the original C type names from this Go file, nor can we determine which types in the current Go file have corresponding types in the C language.)

那你去做？谁会去做这种又傻又累又没有进步的活，只能写自动化工具！

这里你可能误解我的意思了，我的意思是标准库的llcppg.pub的生成，是会由自动化工具来完成的（很有可能直接就由llcppg来支持了），但是当前这个PR实现的这个工具是无法满足这个自动化需求的，因为这个工具的输入是Go文件，其本身并不包含c语言的源信息，无法建立这个映射。

[luoliwoshang]

那你去做？谁会去做这种又傻又累又没有进步的活，只能写自动化工具！

这里你可能误解我的意思了，我的意思是标准库的llcppg.pub的生成，是会由自动化工具来完成的（很有可能直接就由llcppg来支持了），但是当前这个PR实现的这个工具是无法满足这个自动化需求的，因为这个工具的输入是Go文件，其本身并不包含c语言的源信息，无法建立这个映射。

按照你说的，一个一个手工去填，你去做做看，要多久吧。写工具是为了提高效率！

我并没有认为这里不需要自动化工具来转换标准库，只是现在标准库中的已经转换的类型并不多，为了目前的llcppg的进度推进可以先手动去创建系统库是llcppg.pub。
而未来这个自动化转换标准库并生成对应标准库的llcppg.pub的功能是会由一个能接受c语言源文件信息的转换工具来支持（可能就是llcppg）。
但是现在这个PR实现的输入是一个转换完成的Go文件，再去生成llcppg.pub映射文件，这里会缺少c语言原本的信息，从而导致无法实现这个需求。

[tsingbx]

那你去做？谁会去做这种又傻又累又没有进步的活，只能写自动化工具！

这里你可能误解我的意思了，我的意思是标准库的llcppg.pub的生成，是会由自动化工具来完成的（很有可能直接就由llcppg来支持了），但是当前这个PR实现的这个工具是无法满足这个自动化需求的，因为这个工具的输入是Go文件，其本身并不包含c语言的源信息，无法建立这个映射。

按照你说的，一个一个手工去填，你去做做看，要多久吧。写工具是为了提高效率！

我并没有认为这里不需要自动化工具来转换标准库，只是现在标准库中的已经转换的类型并不多，为了目前的llcppg的进度推进可以先手动去创建系统库是llcppg.pub。 而未来这个自动化转换标准库并生成对应标准库的llcppg.pub的功能是会由一个能接受c语言源文件信息的转换工具来支持（可能就是llcppg）。 但是现在这个PR实现的输入是一个转换完成的Go文件，再去生成llcppg.pub映射文件，这里会缺少c语言原本的信息，从而导致无法实现这个需求。

你不是说查找所有c头文件，然后手工写入go对应的类型。然后再手工写pub文件？这个工具目的是为了减少手工工作。你不会连这个都反对。那你去尝试一下全部手工。
要是有方法支持c源文件类型到go的所有类型。估计go标准库已经全面支持了吧。也不需要手工或者自动化工具。

[tsingbx]

For the third-party library llcppg.pub, it will be automatically generated by llcppg

知道，这个工具不是还没有写完吗？为了实现递归生成临时生成。

[tsingbx]

Therefore, we should not, nor can we, implement an automated tool to extract the original C source names to Go names into llcppg.pub from this converted Go file. (We cannot obtain the original C type names from this Go file, nor can we determine which types in the current Go file have corresponding types in the C language.)

那你去做？谁会去做这种又傻又累又没有进步的活，只能写自动化工具！

这里你可能误解我的意思了，我的意思是标准库的llcppg.pub的生成，是会由自动化工具来完成的（很有可能直接就由llcppg来支持了），但是当前这个PR实现的这个工具是无法满足这个自动化需求的，因为这个工具的输入是Go文件，其本身并不包含c语言的源信息，无法建立这个映射。

工具不可能完美，为了减少手工工作。否则打开文件，第一个眼睛就晕了。

[luoliwoshang]

我并没有认为这里不需要自动化工具来转换标准库，只是现在标准库中的已经转换的类型并不多，为了目前的llcppg的进度推进可以先手动去创建系统库是llcppg.pub。 而未来这个自动化转换标准库并生成对应标准库的llcppg.pub的功能是会由一个能接受c语言源文件信息的转换工具来支持（可能就是llcppg）。 但是现在这个PR实现的输入是一个转换完成的Go文件，再去生成llcppg.pub映射文件，这里会缺少c语言原本的信息，从而导致无法实现这个需求。

你不是说查找所有c头文件，然后手工写入go对应的类型。然后再手工写pub文件？这个工具目的是为了减少手工工作。你不会连这个都反对。那你去尝试一下全部手工。
要是有方法支持c源文件类型到go的所有类型。估计go标准库已经全面支持了吧。也不需要手工或者自动化工具。

我没有认为标准库的类型都会由手动来进行转换并填入llcppg.pub。

[luoliwoshang]

这里你可能误解我的意思了，我的意思是标准库的llcppg.pub的生成，是会由自动化工具来完成的（很有可能直接就由llcppg来支持了），但是当前这个PR实现的这个工具是无法满足这个自动化需求的，因为这个工具的输入是Go文件，其本身并不包含c语言的源信息，无法建立这个映射。

工具不可能完美，为了减少手工工作。否则打开文件，第一个眼睛就晕了。

我并没有认为不需要自动化来处理标准库的类型转换和映射信息生成。
我有疑问的仅是这个Pr实现的工具最初的策略是输入为一个已经转换完成的Go文件，其本身不包含c语言原本文件的信息，无法构建这个映射信息（llcppg.pub）。

在当前这个更新中，我看到预期的输入是一个转换完毕的Go文件，并在对应类型末尾增加规定的注释来表明当前类型的来源，那么这个注释和类型就已经表示了映射信息，而这个映射信息在对应的自动化工具（比如llcppg）中是能获取并且输出的，也就能完成llcppg.pub文件的输出，无需再规定一个接口，让llcppg输出符合这个接口规定的类型和注释，再通过这个工具来提取出llcppg.pub。

这里如果我存在误解的话，可以同步一下当前工具的输入输出。

[tsingbx]

这工具不是针对llcppg已经生成的产物。针对无法用llcppg生成的c标准库。

[cpunion]

.pub 文件是哪里使用的？为什么需要这个？

[luoliwoshang]

.pub 文件是哪里使用的？为什么需要这个？

llcppg.pub 是用于 llcppg https://github.com/goplus/llcppg 进行依赖处理的，其描述了C的原始名称及对应的Go名称，在llcppg的转换中，声明了对应的dep llgo package,即会去对应Package中寻找对应的lccpg.pub并读取该文件，并对其对应的类型进行引用。

https://github.com/goplus/llcppg/blob/50efe01377b578f7f1d0c0302de135e9a857f981/doc/llcppg.md?plain=1#L97-L158

比如在某个转换工程中，声明依赖了 github/goplus/llgo/c

{
   "deps":["github/goplus/llgo/c"]
}

那么就会寻找对应Package下的llcppg.pub文件，注册对应的类型映射

llgo/c/llcppg.pub

Lines 1 to 4 in 22524b0

	FILE
	size_t SizeT
	intptr_t IntptrT
	uintptr_t UintptrT

那么对于C头文件中有使用FILE，size_t，intptr_t 等类型时，就可以通过这个保存的映射关系，找到实际引用的转换完成的Go类型

#include <stdio.h>
typedef struct Stream
{
  FILE *f;
  CallBack cb;
} Stream;

import (
	"github.com/goplus/llgo/c"
	"unsafe"
)
type Stream struct {
	F  *c.FILE
	Cb unsafe.Pointer
}

[tsingbx]

.pub 文件是哪里使用的？为什么需要这个？

.pub文件导出llpkg的c类型到go类型的映射关系，目的是为了llcppg转换的时候，在包的作用域内注入第三方包或标准库的类型信息。