Benoît, Will all the controls that are gambas written, be implemented in this fashion too? if so how will the IDE distinguish between a library and a control?
Regards, Dimitris 2010/4/26 Benoît Minisini <[email protected]> > > 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 > > > ------------------------------------------------------------------------------ > _______________________________________________ > Gambas-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/gambas-user > ------------------------------------------------------------------------------ _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
