Forum > General
Calling procedure of library via a script ?
Fred vS:
Hello great fpc people.
Here the story :
A program uses a library.
That library is fpc and can be modified.
Is it possible to access procedures of the library with a variable from the main application ?
Something like this :
=> Library side :
--- Code: ---library mylib;
...
procedure one_of_library_procedure(x, y, z : integer); /// NOT EXPORTED
begin
// something...
end;
procedure run_procedure(theproc : string) ; cdecl; /// EXPORTED
begin
run(theproc) ; //// this the thing...
end;
...
export
run_procedure name 'run_procedure';
end.
--- End code ---
=> Main program side :
--- Code: ---...
run_procedure('one_of_library_procedure(2,4,5)') ;
...
--- End code ---
Many thanks.
skalogryz:
the described approach will work, as long as you're able to parse the passed script (theproc : string).
Thinks about the case
--- Code: ---run_procedure('one_of_library_procedure((2+5)*getsomeval() div 4,4,5)')
--- End code ---
is there a problem exporting the procedure?
btw, OpenGL is using "extensions" mechanism, to describe supported extensions. Each extensions comes with certain set of variables and functions - available as library exported functions.
Thus the main program would parse the extensions list and import functions based of the list. Is this is something you're looking for?
marcov:
Very hypothetical it could work, but of course FPC in library form would hit FPC's GPL license that means that your main program also should be GPL compatible.
There are some practical problems to fix though:
- FPC has no "to memory" abilities only to disc. On most targets external assemblers and linkers are used that expect their input on disc. All this disc writing would be slow.
- FPC generates a new EXE or DLL, and has no facilities for running at all. You would have to engineer for loading and interfacing the compiled result into your own environment.
All of which is non trivial, which is probably why it is not done already.
Fred vS:
@ marcov and skalogryz => many thanks => ;)
--- Quote ---is there a problem exporting the procedure?
--- End quote ---
Hum, exporting the procedures is not the problem, but there are so much to declare that i would prefer to do it via variable.
That library uses AggPas and i want to find a trick to not export all the AggPas functions...
So if the developer want to use some AggPas procedures, he can call it via a variable.
--- Quote ---Thus the main program would parse the extensions list and import functions based of the list. Is this is something you're looking for?
--- End quote ---
Maybe, not sure i understood what you explained...
--- Quote ---Very hypothetical it could work, but of course FPC in library form would hit FPC's GPL license that means that your main program also should be GPL compatible.
--- End quote ---
Aaargh, not sure i understood that too, why this "calling procedures via variable" would alter the license ?
So, to resume, if a library uses AggPas, must each AggPas procedure be exported inside the library or is there a trick to uses that Aggpas procedures without exporting all the procedures ?
Many thanks.
Fred
marcov:
--- Quote from: Fred vS on July 14, 2014, 01:33:35 pm ---
--- Quote ---Very hypothetical it could work, but of course FPC in library form would hit FPC's GPL license that means that your main program also should be GPL compatible.
--- End quote ---
Aaargh, not sure i understood that too, why this "calling procedures via variable" would alter the license ?
--- End quote ---
No integrating the compiler into your application would. As DLL or not.
--- Quote ---So, to resume, if a library uses AggPas, must each AggPas procedure be exported inside the library or is there a trick to uses that Aggpas procedures without exporting all the procedures ?
--- End quote ---
You are mixing too many things. In Windows it must be exported. But while on Linux you might not need to, you only could get the function that way, and still need a declaration to call it.
But calling code in a string is near impossible.
Navigation
[0] Message Index
[#] Next page