Compiling Haxe to be used as a Visual C++ DLL library

[Ricardo Rojas]

Hi,

I want to use Haxe to compile a C++ dll, but even when I compile with the -d flag, I don't get a DLL at all. I've also tried to create my own, but the code haxe gives me creates massive complains from Visual Studio.

What would you recommend?

[Hugh]

Hi,

I would get hxcpp to compile to a static library, and then make a separate VC project to link against this library to create a dll.  

This is very similar to wrapping the code in a exe.  You could then work out when to intitialize the code - maybe in DllMain, or the first time one of your exported functions is called.

Hugh

[Ricardo Rojas]

See, that's the fun thing. I thought exactly the same, I used the .lib file created by the -d flag, but VS refuses to acknowledge the library exists at all. I made sure the library path and the library were added to the projects requirement, but whenever I tried to call the class to expose its methods, it says it can't find it.

[Hugh]

When you link a .lib into a .dll, the linker will chuck away everything it thinks is does not need.  It starts with the non-library ".obj" files, and any "/include" symbols and works out what is needed from there.  If you do not link in either of these, then the linker will probably throw away everything.

So once you have build the haxe-generated .lib file, also include a source file similar to src/ExampleMain.cpp, but with a renamed "main", like:

extern "C"
{
__declspec( dllexport )

int RunHaxe()


{
        // Do this first
        hxcpp_set_top_of_stack();

   // Register additional ndll libaries ...
   // nme_register_prims();

        //printf("Begin!\n");
        const char *err = hxRunLibrary();
        if (err) {
                // Unhandled exceptions ...
                fprintf(stderr,"Error %s\n", err );
                return -1;
        }
        //printf("Done!\n");
        return 0;
}

}

No you should have one symbol (RunHaxe) at least.  It then depends how many haxe functions you want to be able to call.  If it is just a few, I suggest adding wrappers to this source file to keep the API in one place.

Hugh

[Ricardo Rojas]

Ok, I think I understand, but it's not just a few functions, since the whole point was to make a cross-platform framework that exposes a series of services. So you're telling me I would have to create functions for all of those
functions I need to have access to? And what about the classes I need?

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[PSvils]

The way DLL libraries work is that you need to declare which functions should be exported in the DLL. http://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx
So I would argue to actually have hxcpp be able to generate prefixes for certain functions - not sure if you could use macros for this.
VisualStudio generated DLL projects create a handy macro #ifdef where it automatically switches between dllimport and dllexport based on if you're building the library (export) or importing the library (import).

I would eventually be interested in having an easy way to export a haxe dll with hxcpp as well!

P.

[Ricardo Rojas]

Hmmm, I'll investigate that as well. Thanks a bunch guys! If I find a solution I'll post about it here.

[Hugh]

You could try compiling with "-D dll_export". This was not really intended for this purpose, but it might work, ie export everything. These will be the c++ mangled names.

I was thinking you might want to create a "clean" Api, that does not depend on the haxe code implementation.  This way, you would write a fixed set of headers and interface functions, but allow the haxe code to change however it likes, but keeping the changes in the dll "black box".  If you are going the "all symbols" approach, then you will need to expose the haxe generated headers, and the hxcpp headers, to your "application code", requiring a complete recompile if you change something in the haxe code, or have a different version of hxcpp installed or whatever.  In this case, you may as well go the .lib file as the .dll file.

The black box approach is very nice, if you can keep the interface small enough to manually manage.

Hugh