Hi Cogier,
Thanks for the feedback. I really do appreciate you trying this out.
I've been a big fan of the ability to easily use shared libraries in Gambas, and a little dismayed that there is no official Gambas "packaging" methodology concerning them. I don't want to get involved in the messy business of Linux packaging. First, because it is messy, and second because it is Linux specific, even distro specific. Also, I think it is more appropriate to distribute the source code rather than a binary.
Thus, I have crafted a solution where the library is distributed with a "host" application, which will compile the library if necessary (RunSh.module), and has code in it which demonstrates the use of the library's functions. I don't think I can make it much more useful or easier than that.
The glitch in my plan is that I hard coded the assumption that the "host" project would be located in a "~/Gambas/libGambas" directory. This assumption was made due to the compile.sh script needing to have the directory as the current directory. Previously I hard coded the "cd directory" command as the first line in the .sh file (thus enforcing its location). I have changed that so the directory gets passed as a parameter.
Everything should work fine with the host application now.
This missing piece is how do I get the end user to either copy the .so, or make a link to the .so, in the system /usr/lib directory. This requires admin privileges which is something I don't feel comfortable adding to my code, and people would then be understandably wary of using it. If this step is taken, then the path specification in the Library statement is no longer necessary and just the library name can be used.
My new solution is to add a few comment lines near the Library declaration for how to create the soft link. Running the "host" application should now work anywhere. The soft link is only required in order for other applications to access the library simply by name instead of full path.
I've attached the new FFTW library "host" project. I would be grateful for it being independently tested and for any further recommendations.
On the other issue, I am aware of the "&/" operator. I am also aware that it is "syntax sugar" hiding a bit of processing. Therefore, if I know the outcome ahead of time, I will employ the simple "&" instead.
i.e. I will do ( x & "/" & y ) instead of ( x &/ y ) if I know x doesn't have a trailing slash and y doesn't have a leading slash. If either side is a string constant, it is more efficient to add the "/" to the constant than the "&".
Therefore, how I did it:
thePath = "~/Gambas/libGambas/" & ArgLibraryName & "/"
will be more runtime efficient than your two following examples. Plus, you neglected the trailing slash. Including that, and knowing it is there, eliminates the need for &/ downstream and allows for & instead.
In my VB days I used "Path" as a string variable suffix to indicate a directory name having a trailing backslash (Windows style) and "Dir" for a directory name without. The whole drive letter, now root path, thing made that necessary.
Of course, if I don't know, the &/ is a lot better than my own testing.
Thanks for the unused variable reminder. I try to do that. I also try to do a "Project/Clean" before making the archive too.
Ced