and also -llibname -L/usr/lib/.... -I/usr/include...... too
Yes -- though I don't think you'll need /usr/include which contains C system headers (it's not recommended to put your Pascal translations there).
Yes , this could be other directory ex. /usr/pincludes or somthing else if end user will want but i think is good idea to standarize where to put them. Last days i tryed one very good tool 'buildtool' it much faster than autoconf + automake and could be easly expanded to support gnu pascal and automaticaly generate makefiles http://buildtool.sourceforge.net/ so my idea is to standarize where such tools schould search for header files.
- all macro definitions will be converted to macro definitions NOT to
wrpaer functions to avoid not neccesery function jumps in generated code
GPC can inline functions. This is generally just as efficient and often easier to use.
Yes right but more difficult to maintain when original library is changed Best is to maintain original file structure of header files with all ilines and macros as they are with minimal ingerention. Most of macro definitions are very simple and easy to recode.
Why this don't work : we've got an pointer array inside a redord field
type ppointer = ^pointer; type our_rec = packed record
..............
I'm not sure exactly what you did (why don't you post a complete sample code), but in Pascal, pointers and arrays are not the same (FPC is like C in this regard, indeed). If you want to access it as an array, declare an array.
understod, right pointer is not an array in gpc...
Second problem I got in C function like that with variable number of arguments type name (arg,arg, ....)
GPC allows external declarations with `...'.
thx i didn't find anything in manual about ,...) it is good idea to add that i think. ...................
Frank
Artur