cross-platformhaxeflashdevelop

HaxeDevelop: cross-platform compilation via default project templates


Trying investigate how to create "Hello world" on different languages via HaxeDevelop. I'm newbie and may be inacurate at terminology.

1) C# project. Pressing F8 gives me error:

haxe -cp src -cs D:/Programs/Projects/CsTestHaxe/bin/ -main Main
Unix.Unix_error(8, "mkdir", "D:/Programs/Projects/CsTestHaxe/bin/")
Build halted with errors (haxe.exe).

Via googling pretty much outdated info at least found solution:

haxe -main Main -cs out

And it works but ouput go to "src" location which is bad. Next googling led me to "Custom build" and using .hxml with pre-build command at project settings.
But why default template/settings not works for such simple thing as "Hello world" (used cs.system.Console)?
How default build may be fixed / probably I've installed or setup something wrong via HaxeDevelop installation?

2) C++ project. Pressing F8 gives me error:

Warning: Could not find environment variables for Visual Studio
Missing HXCPP_VARS
Error: Could not automatically setup MSVC
Error: Build failed
Build halted with errors (haxe.exe).

Using command line (similar to C# above) I can exucute C++ sources, but cant compile it.
Installed Visual Studio Community 2017. Nothing changed, same error. VS provide different own parts for installation. Should I install any specific?
Found also many threads about OpenFL workaround for C++ compilation. But I needn't OpenFL and want to use default Haxe API and tools.
Also OpenFL and C++ always mentioned with Lime. Do I need it too? Installed Lime via command line. But seems nothing changed.

3) Am I right that HaxeDevelop not yet support HashLink?
And if possible couple words about why HashLink appeared if there is Neko affiliated with Haxe?


As a result here an additional question: is it right that Haxe during compilation to target platform only "convert" .hx source to target one and then using third party (target platform) compile?


Solution

  • 1) C# project. Pressing F8 gives me error.

    This appears to be a known Haxe issue. Since it's been fixed on the dev branch, you could try a nightly build from build.haxe.org. Alternatively, you could also try manually creating the bin directory, since that seems to be what the error is about.

    2) C++ project. Pressing F8 gives me error:

    The latest Haxelib release of hxcpp (3.4.64) does not support Visual Studio 2017 yet. You could use a development version by installing hxcpp from GitHub, since again, it should be fixed there:

    haxelib git hxcpp https://github.com/HaxeFoundation/hxcpp
    

    The alternative is to downgrade Visual Studio.

    Also OpenFL and C++ always mentioned with Lime. Do I need it too?

    Yes, if you want to use OpenFL, you also need Lime, as OpenFL depends on it.

    3) Am I right that HaxeDevelop not yet support HashLink?

    Actually, a HashLink project template was added. But to follow the general theme of this answer, it seems it hasn't made it into an official relase yet. You can get a nightly build from here.

    And if possible couple words about why HashLink appeared if there is Neko affilated with Haxe?

    There is a two-part blog series on haxe.org by HashLink's author: part 1, part 2. The first part has a paragraph talking about this exact topic. Here's an excerpt:

    First, let me explain the reasons for writing another virtual machine in replacement of Neko.

    [...]

    Back then, the Neko virtual machine was not especially designed to run Haxe and suffered from some limitations, the main one being performance.

    [...]

    And to your final question:

    is it right that Haxe during compilation to target platform only "convert" .hx source to target one and then using third party (target platform) compile?

    That is true for some targets, but it depends. For C++, C# and Java, Haxe indeeds generates source code for the target language and then invokes the target-native compiler after doing its own compilation (this step is usually called "native compilation").

    However, some targets produce byte code directly (SWF and Neko), so there is no native compilation step there. Other target languages are interpreted (JS, PHP, Python and Lua), so there's no native compilation step there either. For HL it actually depends, there is HL/Jit (byte code) and HL/C, which is compiled to native C code.

    You can find a comprehensive list of Haxe targets an their characteristics here.

    Phew, that was a lot of questions in one. ;)