[Gambas-user] Distribution of custom shared libraries

Tobias Boege taboege at gmail.com
Sat Feb 23 01:37:11 CET 2019


On Fri, 22 Feb 2019, Cedron Dawg wrote:
> Hi Tobi,
> 
> I did search quite a bit for GamePad support before I wrote my own.  The only thing I could find was an old mailing list entry about reading the "/dev/input/js#" through an EXEC command since the read didn't work.  I've lost the refernence, sorry.
> 
> I think it would be great to have it as a gb.* component, but that is beyond my ability at this point.  Also, apparently the "/dev/input/event##" is the more recent way of doing it, but I haven't figure that out yet either.
> 
> For this project, I am happy to distribute source.  The question I have is not about the Gambas code, rather is what do I do with the .c file?  It is not project specific since it is meant to be usable with any Gambas application.
> 
> On my machine, this is how I have is set up:
> 
> I am putting my projects in my "~/Gambas" directory.  I also have a "~/Gambas/so/<libname>" directory for my library code.  In my "/usr/lib" directory (as root), I added a link called "libGambas_GamePad.so" which points to the same file in my development directory.  This works great.  I can modify the library, compile in place, and test immediately from the Gambas IDE.
> 
> These are my functions:
> 
> Extern GP_GetAttachedList() As String In "libGambas_GamePad"
> Extern GP_FillInfoBlock(argPadIndex As Integer, argInfo As InfoBlock) As String In "libGambas_GamePad"
> Extern GP_RawRead(argPadIndex As Integer, argEvent As EventBlock) As String In "libGambas_GamePad"
> 
> So, if I include the source code in my project, how best to communicate installation instructions for the .so library for the end user?
> 

I didn't realise that you were talking about shipping a shared library with
your project. That changes matters substantially in that architecture does
make a difference. I've never done anything like that and it seems like the
IDE dialogs do not provide means for compiling C sources into shared objects
before packaging -- or cross-compiling options for that matter.

There might be ways to do it, but the most clean solution is a native
component, which is Gambas' term for gb.* components which are written
in C and directly connect the interpreter to some C-level interface.
These are not as easy to write as a C program or a Gambas component and
they have to be included in the Gambas source tree.

As I said, I have such a half-baked component on my computer (apparently
from 2015!). Maybe we should exchange ideas and turn your and my component
into something that can be included in the Gambas source tree. From that
point on, Linux distributions will take care of architecture dependency
when putting Gambas into their repositories. It will also free you from
worrying about receiving Structs from Extern functions. Native components
have a nicer way of making C-level data structures available to Gambas
programs.

I'm taking a look at your C file.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk


More information about the User mailing list