Hi Przemek,
On 2010 Feb 16, at 16:21, Przemysław Czerpak wrote:
> On Tue, 16 Feb 2010, Szak�ts Viktor wrote:
>
> Hi Viktor,
>
>> I still can't see how exactly, but I hope we
>> can make this process smoother in the future.
>> For sure hbstatic is a good step, after that
>> we can see the next.
>
> Now I am confused :)
>
> hbstatic library is completely independent extension which interacts
> only with point 2 I described and when it will be ready instead of
> #pragma {begin/end}dump it will be possible to simply use:
> REQUEST HB_DYNAMIC_PCODE
> but this is all what will be changed so I do not know what are
> the next steps you are talking about.
So it's not completely independent :)
> There are few methods of creating DLLs because it's possible to
> create _different_ DLLs. Programmer has to chose the method which
> is the best for him depending on the type of application and context
> were they are used.
>
> DLLs can be linked statically or loaded dynamically with/by static
> or shared (using harbour*.dll) applications. They can use static or
> dynamic bindings to functions in core part of application or
> in harbour*.dll.
>
> The method chosen to create DLL depends on users needs. I.e.
> if I want to allow to creating 3-rd party extensions to my
> application which can use any public functions linked with
> my program then the ideal seems to be creating import libraries
> for my binaries and distribute this library to all 3-rd party
> programmers so they can link their code with it.
>
> But if I want to create DLL which can be loaded by many
> different application linked statically or dynamically then
> such DLL has to be linked with hbmaindllp.
>
> If I want to help programmers working on such DLLs then I can
> give them list of functions which are available in core part
> of application in .ch file declared as DYNAMIC.
> Using such .ch file they can easy verify at DLL link time (link
> time errors) if they used some functions which are not available
> in the main application code and where not REQUESTed from Harbour
> libraries.
>
> This is rather simple functionality which users may need in
> different situations so all methods are important.
Good description of "use cases". My idea is to make
above combinations as easy as possible to use. Maybe it's
not possible, maybe it is. Question is what items can be
automatized in above cases. If there is some which can,
we can add more -hbdyn* switches to let hbmk2 deal with
some details (linking hbstatic, linking hbmaindll*, creating
list of DYNAMIC symbols, etc)
You'll probably much better see if such thing can be
added, so just keep it mind to drop me a notice.
> It's also possible to create much more complicated binaries, i.e.
> using few independent HVMs in different DLLs but I do not want to
> document it. Such functionality is for really advanced users who
> well know what they are doing so they do not need any description
> how to make it. Most of other users will only create broken binaries
> which will not work as expected.
Yes, I agree to leave these.
There is one which might be interesting for more users:
If someone wants to create a "pcode" .dll which can be launched
from other systems, like C#/.NET, pure .c, or Python projects.
I wonder, if this is possible currently, or at all?
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
