Hyperion Entertainment Message Boards

Hi all

I've got a load of code that I'm trying to convert into a native amiga program and I've got a question about converting some shared utility function libraries. I've got them as dll and so files on windows and unix. Given the nature of the program, keeping them as shared objects is quite expensive as the program also consists of a load of plugins (as shared objects) and the overhead of reloading the utility libraries as shared objects for each one is too much. The libraries only export functions, no data, so they should be ideal candidates for normal amiga shared libraries.

After playing around with idltool, I'm starting to see how the xml and code fit together but I have a couple of questions.

1. Is the struct interface *self parameter a requirement? My code itself doesn't need it, since it doesn't have any private library specific data, and it would mean that I could just use the same prototypes that are in the library already. Or do I need to create a load of stub routines that include the self parameter that simply call the original prototype. For example, is it enough to have something like
or must I have something
2. Looking at idltool it generates the c/h files from an exsiting xml file; for my situation I want to go the other way since I already have the c/h files and would need to generate the xml file. There about a 1000 functions so it could be quite time consuming to generate this interface xml file by hand, so I've started toying with the idea of writing a parser program to scan the header files and produce this xml file. Am I duplicating something that already exists here?

cheers

billy

Greetings.
I have a little experience. If I give a bad answer, I trust someone will
be helpful and correct me.

Is the struct interface *self parameter a requirement?

Yes. All native libraries use interfaces.

Looking at idltool it generates the c/h files from an exsiting xml file;

In addition to the .c files, it creates all the files that define your library.
Doing these manually would be tedious and error prone. I strongly suggest
letting idltool handle the "housekeeping".

There about a 1000 functions

That's quite a few functions. Do they divide naturally into smaller groups?
If they can be arranged into logical subgroups of a larger library, it would
be easy to create multiple interfaces within a single library. Most libraries only
have a "main" interface, but when it makes sense to subdivide, it's easy to do.
For Example expansion.library has main and pci_device interfaces.
Again, a good reason to let idltool create your framework.

I've started toying with the idea of writing a parser program to scan the header files and produce this xml file.

I see no reason why not. It sounds like a good idea.
I do not know of any existing tools to do this for you, but there is much that I don't know.

I'm not the expert, but I hope my reply helps!
LyleHaze

@LyleHaze

Thanks for this LyleHaze (and also for the audio driver, nice work there! )

In addition to the .c files, it creates all the files that define your library.
Doing these manually would be tedious and error prone. I strongly suggest
letting idltool handle the "housekeeping".

Agreed! The issue is really that programmer trait of laziness The idea of filling in the xml file by hand doesn't appeal which has led me to thinking that writing a parser program to produce the xml (or fd) file is better in the long run.

That's quite a few functions. Do they divide naturally into smaller groups?

er, possibly! I think that the porting process will force me to look at subdividing these into separate subgroups. The more modular I can get it, the easier it will be to handle.

cheers

billy