[Gambas-user] Compiled version of class

[Brian G]

I have suggested before, Is it time to have something equivalent to pip in python for gambas to distribute gambas components and libraries, Making it independent of os as much as possible?

Everything around distribution would be so much simpler.

That said I am not sure just how much distro specific stuff is in the core components.

ummmm.

Thank You
Brian G

----- Original Message -----
From: "Bruce" <adamnt42 at gmail.com>
To: "Gambas mailing list" <user at lists.gambas-basic.org>
Sent: Saturday, January 16, 2021 10:53:00 AM
Subject: Re: [Gambas-user] Compiled version of class

On 14/1/21 4:14 am, Olivier Coquet wrote:
> Hi, i try to make a component and after read the doc, component is 
> working, but....
> 
> If I understand all, component is distribution dependent, if i publish 
> it in deb format, Fedora can't install it ???? (for example)
> 
> This is a constraint.
> 
> Olivier Coquet

Getting back to the original post, let's get rid of some misinformation 
floating around.

1. A component is almost like a shared library i.e. like a 
"libsquiz.so.1.0.67" so it has to be installed on the system where the 
client application is installled. It's not a shared library because it 
is not directly executable code - it's in the Gambas precompiled 
thingo-code format (like java). So it lives in special directories known 
to the Gambas executor (gbr3).
So you need to install it in order to use it. One of the easiest ways to 
do that is to use the Gambas IDE packager.
Of course, this is distribution dependant, just like any oher program 
built in any other language. Debian packages wont work on rpm based 
distros, rpms wont work on debian based distros. However, the same 
Gambas CODE can be packaged to suit the listed PACKAGING formats. So its 
maybe a "constraint", but its not a Gambas constraint.

2. It is HIGHLY RECOMMENDED that you write your test harnes s code for 
your component (or indeed libray) inside the component project. The 
class(es) that you are exporting will work EXACTLY the same way that 
they will when used in a client project.If you want to when your 
component works, you could excise the test code from the project. We 
here don't bother, we just make sure none of the test harness is exported.

3. Gianluigi is incorrect when he says that libraries are in the ~.local 
heirarchy. The are only there on the machine for the user who compiled 
it. For example if you are on a multi-user machine, either everyone has 
to compile the library or you have to install the library the same way 
as for a component.

Finally a short comment on multiple Gambas versions on the same machin, 
including multiple versionsof custom components and libraries. We have 
been doing this for years. The design is based on how programs like 
postgresql allow for multiple versions. The trick is to install in /opt 
and use the GAMBAS_PATH env settiing (or whatever it was that Benoit 
mentioned. Then all you need is a shell script that uses that root path 
setting. Wehave never had a problem. At the moment our testing system 
has the "pure" Gambas, two local Gambas' with certain customised things 
(including the IDE) and two other versions (one native and one 
localised) that provide the platfomrs for different versions of our own 
custom controls and components and libraries - "production" and 
"testing". None of these intefere with each other and all use the proper 
shared code files.

hth
bruce

----[ http://gambaswiki.org/wiki/doc/netiquette ]----