[ITP] biosig [was: Re: newcomer issues when packaging biosig, stimfit, etc.]

[Alois Schlögl]

Am 1/14/22 um 11:09 schrieb Marco Atzeri:
> On 12.01.2022 23:59, Alois Schlögl wrote:
>>
>>
>> Am 1/12/22 um 06:47 schrieb Marco Atzeri:
>>>> In the meantime, please find below the status for the libb64 and 
>>>> biosig packages.
>>>
>>>> Thanks that was helpful. Attached is an updated version for biosig 
>>>> and libb64.
>>>>
>>>> cygport libb64.cygport all
>>>> cygport biosig.cygport all
>>>>
>>>> runs now w/o error. How can I test whether result can be installed 
>>>> and used ?
>>>
>>> One major problem.
>>> Never build in the source directory, the final src.patch
>>> must fit with you desired patch.
>>> So only what you patched should come out.
>>>
>>> For this package that does not respect the build in a
>>> different directory than source, you shoud start
>>> with something like:
>>>
>>> src_compile() {
>>>         cd ${S}
>>>         lndirs
>>>         cd ${B}
>>>         cygautoreconf
>>>         cygconf
>>>         cygmake
>>> } 
>>
>>
>>
>> I've adapted biosig.cygport accordingly and addressed this in the 
>> attached version. It runs fine when doing
>>
>>     cygport biosig.cygport all
>>
>> runs w/o error. Also testing the package with
>>
>> tar -C / -xvf 
>> biosig-2.3.3-1.x86_64/dist/biosig/biosig-tools/biosig-tools-2.3.3-1.tar.xz
>> tar -C / -xvf 
>> biosig-2.3.3-1.x86_64/dist/biosig/libbiosig/libbiosig-2.3.3-1.tar.xz
>> tar -C / -xvf 
>> biosig-2.3.3-1.x86_64/dist/biosig/libbiosig-devel/libbiosig-devel-2.3.3-1.tar.xz 
>>
>>
>> and running
>>     save2gdf -h
>> works fine.
>>
>> Moreover, I understand now why my libb64.cygport file is not ready. 
>> ecause libb64 is not necessary for libbiosig's support of Stimfit, 
>> I'll omit libb64 for now.
>> Would you please check whether Biosig is ready to be included in 
>> cygwin ?
>>
>>
>> Cheers,
>>     Alois
>
>
> Hi Alois.
>
> it is almost fine


Hi Marco,

thanks for the feedback.


>
> the only problem I see is that the shared library are build as
>
>   libbiosig.dll while they should be called cygbiosig.dll
>   (probably better cygbiosig-3.dll to handle the SOMANE)
>

I tried to do that, but run into issue. The exe-files still expect 
libbbiosig.dll, and do not recognise cygbiosig-3.dll
It seems this would require significant changes by upstream, also by 
other projects that would make use of libbiosig (e.g. stimfit, 
sigviewer, python-biosig, etc.)
Since I do not under stand the purpose of renaming libbiosig to 
cygbiosig, I'm reluctant to go that route.
What kind of problems is this renaming supposed to solve ?

Concerning SONAME-versioning, I'd like to avoid this for now, and 
introduce versioning only when its really needed.
In the foreseeable future, I do not expect any changes will be needed 
that would break the API

> please also run the test in the ${B} directory

Done, this works without error. Please adapt that change accordingly.

>
>
> I was playing with the CMakeList.txt to see if that was more easy
> than your deep patch of the upstream Makefile's
>

I'm afraid that this "deep patch" is just an accidental artifact.
When running configure, all Makefile are rebuild from Makefile.in,
The Makefile(s) were packaged just by accident in v2.3.3.
But in fact these Makefiles should not have part of the released package.



Cheers,
   Alois