Re: [PATCH] build: support building static library

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2024/6/6 11:17, Chen Linxuan wrote:
> 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.

That is also fine with me, anyway, liberofsfuse is a very special
case for us, I'd like to just build a static library for
erofsfuse only (because liberofs will be exported as a dynamic
library in later versions, I don't want to rely on random libfuse
interface).

For other usage, I'd suggest form some formal APIs in liberofs
instead.

Thanks,
Gao Xiang

> 
> 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
>>>>>>
>>>>>>
>>