[Gambas-user] About library and component packaging in Gambas 3

[Benoît Minisini]

Le 29/04/2012 06:45, Bruce Bruen a écrit :
>
> SUGGESTION: Libraries should not need to have a startup class.  At
> the moment I "must" include a dummy module to prevent any
> test-harness code leaking into the user environment (which could
> cause damage if the library were to be run as a normal gambas
> executable.)  At the moment the IDE will not let a library be made
> into an executable or packaged unless it has a startup class.  It
> would be preferable that projects defined as libraries would not
> execute via the runtime, that way test harness code could be left in
> place.  Currently I have to check that the coders have left the
> startup class pointing to the following:-
>
> ' Gambas module file
>
> ' Null module to provide a fake startup point
>
> Public Sub Main()
>
> Error "Please do not run this as a program. It is a gambas library."
>
> End
>

Mmm. You are right, for libraries the IDE should let you not defined a
startup class. I will see what I can do.

> Not sure about this as far as the autotools packager is concerned.
> The icon.png is certainly in the gzip file (but is this because
> autotools is a "source" level package?)

autotools is not reliable at the moment as it didn't get the same recent
modifications as the other package types.

>> - The package has dependencies on other components and libraries
>> checked in the project properties dialog.
> This is unclear.  I was under the assumption that the Project
> Properties dialog Components and Libraries tabs indicated the items
> that are needed when running the library within the IDE (i.e. in test
> mode) and the Component Properties dialog defined the dependencies
> for the library when it runs as a library i.e. in another application
> (whether that application is running in the IDE or via gbx3).
>
> We use a few "private" libraries to develop and test the libraries
> we distribute to users and the approach I have been using is to
> include them in the "Project Properties" dialog but not the
> "Component Properties" dialog.  (Again, this relates back to
> including test harness code in the library and perhaps Issue 123.)
> Could you clarify please.
>

Sorry, this is unclear indeed.

You are right, it works like components: dependencies are managed by the
IDE from the *component/library* property dialog. What is checked in the
project property dialog is taken into account only when running the
library as a normal project.

Usually, dependencies defined in the project property dialog (used when
compiling the project) are the same as those defined in the component
property dialog (the true runtime dependencies). But this is not mandatory.

> Further, it is unclear what the "Extra Dependencies" step in the RPM
> based packagers is for?  Perhaps a little note in the header, similar
> to the "Extra files" step.

They are dependencies added to the package dependency list verbatim. 
These should be name of packages of the target distribution.

For example, if your project uses a system library through extern calls, 
you should add it to the extra dependencies. Because Gambas cannot do 
that automatically, as the name of the library binary package depends on 
the target distribution.

>
>>
>> 2) COMPONENT
>>
>> - There is a library/component properties dialog. - No icon is
>> packaged. - No menu entry is defined in the package. - If the
>> project has control icons, they are packaged. - The package name is
>> "gambas-vendor-projectname-X.Y.Z" where "X.Y.Z" is the version. -
>> The vendor prefix is mandatory, it is "gb" by default. - The
>> package has no dependencies on other components and libraries. This
>> is supposed to be managed directly by the IDE. Components are a
>> special beast that should be included directly in Gambas sources.
> Again,this last bit is unclear.  We use some custom control
> components in our product.  Some of which have dependencies on native
> gb components, e.g. gb.db and at least one of which is dependent on
> another home grown component (i.e. our "phDataControls" component is
> dependent on both gb.db and our "phBaseControls" component.  This has
> worked fine until now.  I haven't checked this yet but does it mean
> that from 4687 on, that this will no longer work?

See the explanation above. Components and libraries dependencies work 
the same way now.

>
>>
>> 3) NORMAL PROJECT
>>
>> - There is no library/component properties dialog. - The "make
>> executable" dialog can create a desktop shortcut automatically. -
>> The packager has an icon and a menu entry. - The package name is
>> "ProjectName-X.Y.Z" where "X.Y.Z" is the version. - The vendor can
>> be added as a prefix optionally. - The package has dependencies on
>> other components and libraries checked in the project properties
>> dialog.
>>
>> Please try it and give your remarks!
>>
>> Regards,
>>
>
> I have checked the autotools packaging (which is how we have
> hitherto been distributing our product to end users) and it works
> fine.
>
> I tried using the Mandriva and Fedora RPM based packaging, which
> allowed me to create proper looking distribution packages, but ...
>
> When I tested the installation locally I run into the following
> problem. There is a dependency requirement on "gambas-runtime"
> version 3.blahblah ... This makes sense except that there is no
> "gambas-runtime" for my home made system, I build and install from
> the source archive. Also, this is how we have set it (gambas) up on
> all the client's machines. Is there a way to remove this dependency
> from being included in the RPM package build?

A binary package system relies of being used totally. You cannot have 
some of the dependencies outside of it (i.e. installed from sources), it 
breaks the system.

This is the reason why Gambas should be packaged eveywhere. :-/

Regards,

-- 
Benoît Minisini