[Gambas-user] "User components" replaced by "Libraries" in Gambas 3

[Benoît Minisini]

> Ian Haywood ha scritto:
> > svitoos wrote:
> >> I think it is better to look for libraries in the directories listed in
> >> GB3_LIBRARY_PATH, and if this variable is not defined
> >> then "/usr/lib/gambas3:/usr/local/lib/gambas3":~/.local/lib/gambas3
> > 
> > I think this is a good idea, because gambas should behave like other
> > POSIX-based interpreted languages (python, ruby, perl, etc.) unless
> > there is a good reason not to.
> 
> I agree too.
> 
> > Benoit wrote:
> >> As they are libraries, looking inside <gambas installation
> >> prefix>/lib/gambas3 may be a good solution, but Gambas executables are
> >> architecture-independant, so maybe they should go into <gambas
> >> installation prefix>/share?
> > 
> > "lib" is where python and ruby libraries go, even though technically
> > their bytecodes are architecture-independent too, this is probably
> > because "lib" has all the other
> > system libraries and its more confusing to make an exception.
> 
> Probably I am wrong, but I don't see all this importance about keeping
> some files in .../share just because they are architecture independent.
> I don't see any advantage in this convention; it would be more logical
> if .../share contained files shareable by different applications on the
> system (and, in fact, you find many of them: icons, fonts,
> translations...). If so, then gambas libraries are not common to
> different applications - they are common to gbx3, and .../lib would be
> more logical.
> 
> >> I don't want to multiply the directories where libraries must be
> >> searched for
> > 
> > I think there is a good reason for the three directories suggested above.
> > It is important to search both /usr/ and /usr/local/ to provide a
> > clear separation between default libraries managed by the OS
> > installation system (apt-get, rpm, or whatever)
> > and third-party libraries installed by the system admin, plus it is
> > useful to have a third directory under $HOME so libraries can be
> > installed without being the superuser.
> > 
> > Ian
> 
> Agreed again.
> 
> And now a little curiosity: would be those libraries *true* executable?

They are.

> I mean - I code a project with some class, and the main class contains
> code to test the other ones. Then I can use the project as a library,
> and still use it as a standalone program to test the library at any
> time. In addition, the project/library can be used to configure it... I
> mean - I use, say, an SMTP library. In my final application, instead of
> asking the user a lot of parameters about the network, I can simply
> SHELL ".../libsmtp.gambas" to let the library ask and store all the
> relevant parameters and preferences...
> 
> Regards,
> Doriano
> 

There is no difference at all between a library and a executable. A library is 
just an executable that is used as a component by another executable.

So you can do what you want!

Regards,

-- 
Benoît Minisini