Adriaan, thanks a lot for sharing this. This will be quite useful for those who want to use IPP with Pascal.
btw, if it is used with IPP 2017 or future update release, do it need to change any thing?
Yes, it needs to be changed for 2017 and future releases.
To see what is changed for 2017, I created a .diff between the C headers of version 9 and 2017. Most changes seem to be minor edits, like clarifications in the comments, header layout changes or changed parameter names (like "KernelSize" being renamed to "kernelSize"). Obviously, what I need to change for Pascal for 2017 is
1. remove calls that are no longer in the libs
2. add new routines
3. edit declarations of calls (of the same name) that have changed parameters lists. Or does this never happen ? In other words, are there ever ABI changes between versions of routines of the same name ?
Of course, I can find out the changes from the .diff of the headers. But if engineering has a precise list of the ABI changes (apart from minor edits) that would save me some time.
Adriaan van Os
Thank you a lot for your work. It is very impressive! The most time we resolve customer's problem with IPP but somebody wants to help us :) May be you have enough enthusiasm to develop IPP interfaces for Python language too?
What I know about Python is that it is "a family of nonvenomous snakes found in Africa, Asia, and Australia" …..
But without kidding, if Intel likes the idea of ipp headers being available for different languages (C, Pascal, Fortran, Assembly, Ada, Swift and Python), think about a database solution:
1. You would need a C parser (once) to get all the information from the headers (comments. types, constants, procedures, parameters, types, etc.) into a database. I would vote for PostgreSQL, but there are other possibilities, like XML files.
2. The database would have some added fields for language options not available in C (and thus not present in the C headers) like whether a reference parameter is a pointer or a VAR in Pascal.
3. For each language for which headers are needed, an emitter is written that walks the database and auto-creates headers for the language. In the first place for C, but then for other languages (needs to be done only once). I will be pleased to write the emitter for Pascal and help otherwise.
4. The consequence is that, for the published API, engineering must maintain the database (or XML files) rather than the C-headers themselves (as these will be auto-created)
5. With that in place, more possibilities will emerge, for example
* add fields to the database (and write an emitter) to auto-create documentation in html and pdf format
* add fields for internal comments/documentation by engineering
* add fields to related bug reports
* add links to the revision history database
I feel this is better than doing the same work again for each language and each release.
Adriaan van Os