Parser mapping

[iexavl]

I have a question about the javacpp parser or rather how to map this properly. I read up on the mapping recipes but I either missed it, it went over my head or it isn't there(probably one of the first two). I have a function that pretty much just allocates an object on the heap and returns the pointer to that object. The function looks like this :

DLLEXPORT lve::WindowContext* VideoContext::alloc_window_context();

When I give the parser the header it generates a class that extends FunctionPointer called Int_Alloc_window_context and the function ends up looking like this :

public native Int_Alloc_window_context alloc_window_context();

how can I tell it to make the return type WindowContext?

[iexavl]

Another question is how can I build a class like how they are built in the ffmpeg wrapper? Like there the classes look like this :

for example the avutil folder with classes inside it that all have this annotation @properties(inherit = org.bytedeco.ffmpeg.presets.avutil.class)
and they are just public class X extends Pointer and than you get the class. When I parse a header file I get a
public class <name of specified target in the @properties annotation> extends .
and inside of that class I get a public static class with the name of a parsed class from the header file that extends pointer.

[saudet]

how can I tell it to make the return type WindowContext?

It will do that by default as long as you include the header file containing the typedef for WindowContext.

Another question is how can I build a class like how they are built in the ffmpeg wrapper?

You'll need to specify a global class in addition to a target package, just like the presets for FFmpeg, yes:
https://github.com/bytedeco/javacpp-presets/blob/master/ffmpeg/src/main/java/org/bytedeco/ffmpeg/presets/avutil.java#L45

[iexavl]

how can I tell it to make the return type WindowContext?

It will do that by default as long as you include the header file containing the typedef for WindowContext.

Another question is how can I build a class like how they are built in the ffmpeg wrapper?

You'll need to specify a global class in addition to a target package, just like the presets for FFmpeg, yes: https://github.com/bytedeco/javacpp-presets/blob/master/ffmpeg/src/main/java/org/bytedeco/ffmpeg/presets/avutil.java#L45

I had another comment before this but I fixed everything for the most part. The problem actually had to do with the DLLEXPORT define. the define looks like this : #define DLLEXPORT __declspec(dllexport). After I removed the define and just used __declspec(dllexport) it worked. Any way around that? Also now I am doing it like it is with the ffmpeg wrapper but I wonder how do you build the dlls? Because now I have multiple classes, do I have to give them to the parser one by one to build?

edit: by the way do the constructors and destructors of the classes I am parsing need to be marked with __declspec(dllexport) ? Because the compiler seems to be complaining about that.

[saudet]

The C++ compiler on Windows do need those, but JavaCPP doesn't, we can tell it to ignore them:
https://github.com/bytedeco/javacpp/wiki/Mapping-Recipes#ignoring-attributes-and-macros

[iexavl]

The C++ compiler on Windows do need those, but JavaCPP doesn't, we can tell it to ignore them: https://github.com/bytedeco/javacpp/wiki/Mapping-Recipes#ignoring-attributes-and-macros

yup, that did the job. What about the dlls though? I have a couple of classes the mapper parsed and now I need to run the command java -jar javacpp. path/to/class/Class.java
and that's going to compile them into dlls right? Do I need to run that for each individual class?

[saudet]

If you want to pass a source file like that, yes, it supports only a single file at a time.

[iexavl]

If you want to pass a source file like that, yes, it supports only a single file at a time.

not a source file , what I mean is right now when I parse my header files java classes are generated from the classes in the header files. Do I need to run the parser on these java classes as well?

[saudet]

We need to run the builder on those classes as well yes:
https://github.com/bytedeco/javacpp/wiki/Mapping-Recipes

[iexavl]

We need to run the builder on those classes as well yes: https://github.com/bytedeco/javacpp/wiki/Mapping-Recipes

Right, probably with some sort of script. I think I read about that somewhere too. Last thing I am concerned about is I had to dllexport my native constructors and destructors, any idea why that might be? For these classes I have disabled the copy constructor:

	WindowContext(const WindowContext&) = delete;
	WindowContext& operator =(const WindowContext&) = delete;
		

(WindowContext is one of the classes I had to export the constructor and destructor for the parser to not throw a linking error)
Could that have something to do with this?

[iexavl]

We need to run the builder on those classes as well yes: https://github.com/bytedeco/javacpp/wiki/Mapping-Recipes

Right, probably with some sort of script. I think I read about that somewhere too. Last thing I am concerned about is I had to dllexport my native constructors and destructors, any idea why that might be? For these classes I have disabled the copy constructor:

	WindowContext(const WindowContext&) = delete;
	WindowContext& operator =(const WindowContext&) = delete;
		

(WindowContext is one of the classes I had to export the constructor and destructor for the parser to not throw a linking error) Could that have something to do with this?

and here is an image of the linking errors if it helps

[saudet]

You'll need to link with the libraries containing those symbols.

[iexavl]

You'll need to link with the libraries containing those symbols.

I have done that. Those symbols are contained within a DLL that I link but I still don't understand if I need to make them callable from a program that imports the dll or leave them as internal functions of the dll.