[PATCH] build: support building static library

[Chen Linxuan]

On 2024/6/6 11:13, Gao Xiang wrote:
> 
> 
> On 2024/6/6 11:06, Chen Linxuan wrote:
>> On 2024/6/6 10:45, Gao Xiang wrote:
>>>
>>>
>>> On 2024/6/6 10:25, Chen Linxuan wrote:
>>>> Hi,
>>>>
>>>> On 2024/6/6 10:22, Gao Xiang wrote:
>>>>> Hi,
>>>>>
>>>>> On 2024/6/6 10:13, Chen Linxuan wrote:
>>>>>> Hi Xiang!
>>>>>>
>>>>>> On 2024/5/23 16:05, Gao Xiang wrote:
>>>>>>> Hi Comix!
>>>>>>>
>>>>>>> On 2024/5/23 15:31, ComixHe wrote:
>>>>>>>> In some cases, developer may need to integrate erofs-utils into 
>>>>>>>> their
>>>>>>>> proejct as a static library to reduce package dependencies and
>>>>>>>> have more finer control over the feature used by the project.
>>>>>>>
>>>>>>> Thanks for sharing this.
>>>>>>>
>>>>>>>>
>>>>>>>> For exapmle, squashfuse provides a static library 
>>>>>>>> `libsquashfuse.a` and
>>>>>>
>>>>>> We want a static library for running fuse-erofs, maybe 
>>>>>> liberofsfuse or something like that, to make a appimage like 
>>>>>> bundle with erofs.
>>>>>>
>>>>>> For quite a long time, Appimage guys patch the fuse program of 
>>>>>> squashfs to get such a static library, and this patch is accepted 
>>>>>> by Debian.
>>>>>>
>>>>>> https://github.com/AppImageCommunity/libappimage/blob/master/src/patches/squashfuse.patch
>>>>>>
>>>>>> https://salsa.debian.org/sgmoore/squashfuse/-/commit/489b04eb7f5e45478f2ba5cd8d7173bb96
>>>>>>
>>>>>> The patch just make a binary to be a static library by changing 
>>>>>> `main` to `fusefs_main`.
>>>>>>
>>>>>
>>>>> Since squashfs don't have any offical libsquashfs, so I guess they 
>>>>> tried
>>>>> export the squashfuse project as a library.
>>>>>
>>>>> But erofs-utils is quite another story since we already have an 
>>>>> offical
>>>>> `liberofs` concept.   If you'd like to export some FUSE interface, 
>>>>> would
>>>>> you mind moving some logic in fuse/ to lib/?  Does this way also work
>>>>> for you?
>>>>
>>>> Sure.
>>>>
>>>> We will send other patches later.
>>>
>>> Err, sorry, a second thought.. If you just would like
>>> to move all code from fuse/main.c to lib/,  I also think
>>> it's somewhat strange.
>>>
>>> So just address your requirement (erofsfuse_main), would
>>> you mind just export liberofsfuse static library instead?
>>> Since it's a bit tangled with libfuse version, so I'm now
>>> hesitated to move into lib/...
>>
>> So you mean that I should export a static library call "liberofsfuse".
>> And the only function it has is erofsfuse_main. Am I right?
> 
> You could export any function in the fuse/main.c, also you
> could rename main() as erofsfuse_main() for the liberofsfuse
> library.
> 
>>
>> But where should I place the source code of this new library? 
>> "liberofsfuse/", "lib/fuse" or somewhere else?
> 
> Just like the current patch, fuse/main.c is okay for me (since

Maybe you want to check the original patch again?

We build liberofsfuse with -Dmain=erofsfuse_main at that patch, which 
sounds like what you suggest here.

Thanks,
Chen Linxuan

> it's tangled with libfuse internals), but I guess we'd better
> to avoid self-contained libmkerofs and more.  `liberofs` is
> much better to be directy used for mkfs, fsck usage.
> 
> Thanks,
> Gao Xiang
> 
> 
>>
>> Thanks,
>> Chen Linxuan
>>
>>>
>>> For mkfs, I guess we will have offical API interfaces for
>>> users to build images later, so libmkerofs is not worthwhile.
>>>
>>> I'm not sure dump.erofs is useful too since low-level APIs
>>> are provided. As for fsck, it's similar to mkfs in the future.
>>>
>>>
>>> Thanks,
>>> Gao Xiang
>>>
>>>>
>>>> Thanks,
>>>> Chen Linxuan
>>>>
>>>>>
>>>>> Thanks,
>>>>> Gao Xiang
>>>>>
>>>>>
>