Configure 32-bit vs 64-bit builds

[pewsplosions]

On Windows I typically use scoop to install all my tools. For C/C++ compiler I use gcc (it is mingw) usually, mostly because I don't want to install a bunch of Microsoft tools just to get a compiler and can just do a quick scoop install gcc and start coding.

I've been reading a lot about using native libraries with Haxe and ammer keeps popping up and seems great but I have yet to actually get it to work. When I tried the sample I can build the dll just fine. But when I try to run the build hxml I always just end up getting this error:

'U:\Projects\ammer\samples\poc\nmake' is not recognized as an internal or external command,
operable program or batch file.

Which, I thought, was because I did not have msvc installed. In Config.hx the useMSVC boolean is not actually determining if msvc is present but instead is just checking if it is on Windows. So obviously ammer is not accounting for other possible compilers on Windows.

However. I used scoop to install msvc after this (it is scoop install visualc if anyone is interested.)

Checked that nmake was on my path. Then tried to build the sample again and got the same nmake is not recognized error. Even though in the same terminal afterward I could type nmake and get nmake.

So, obviously my first request would just be to let ammer work with gcc on Windows. But I'm also curious if anyone else is getting this nmake problem on Windows with msvc/nmake installed and working otherwise or if it is just me (perhaps because scoop isn't installing something?)

I hope I've described my issue well enough. I wish I could just figure it out myself but for the life of me cannot wrap my head around using native libraries with haxe, with or without ammer... so any help either way would be awesome! Thanks!

[Aurel300]

'U:\Projects\ammer\samples\poc\nmake' is not recognized […] or batch file.

I think this error should have been fixed in 85ad75e, do you need to git pull the repo by any chance?

So obviously ammer is not accounting for other possible compilers on Windows.

Well, kind of. ammer.msvc is indeed true by default on Windows, false elsewhere. You can still override the default manually with -D ammer.msvc=false. The problem with supporting other compilers is not that they have a different name, but that they take different types of command-line switches. GCC and clang, the two major compilers, happen to have a compatible interface. MSVC has different switches, hence the MSVC option in ammer.

[pewsplosions]

@Aurel300 Thanks for the info! Here are my findings:

1. You were right about the git pull. I must have originally pulled just before that commit. After updating I no longer get the nmake error.
2. Adding the -D ammer.msvc=false does switch it over to use the gcc compiler.

When I was trying to build the sample project I was getting some odd errors specific to the sample code, after I deleted it all down to just the adder function though I built it and using msvc was able to actually get it all the way to the hl run and see the add work through Haxe. So that's pretty cool.

When trying with gcc I'm getting some 'skipping incompatible' errors in regards to hashlink's library. From what I've read that typically means trying to link 32bit binary to 64bit target or vise versa. The gcc command has m64 so I'm gussing this means my hashlink library installed is 32 bit and my gcc is 64 and trying to build the adder library with 64 isn't working with 32 HL... but I guess this isn't technically an ammer issue, so I'll probably try to look into that later. Unless you have suggestions.

Ammer is pretty cool, I hope to see it keep growing. Being able to easily add libraries to Haxe like this would be a huge benefit to the language as a whole I think. Keep up the good work!

[Aurel300]

@piboistudios

Sounds like an there needs to be an abstraction over compilers; I find that there's somewhat a one-to-one relationship between cl.exe and gcc so if clang is compatible then an interface can describe them all.

I can get to work on this if you are taking PRs @Aurel300

I have something like this in mind. There is a lot of code duplication between all the ammer.build classes. I will probably switch them to producing a list of "build X from Y using Z" to represent Makefile rules, where X and Y are filenames and Z is some enum over compiler commands. There are some specifics to each platform, but in the end they might just be defines, include paths, and library names (-lhl).

I am also thinking that maybe ammer should not rely on make (or nmake) at all. It is not a huge problem because it depends on a compiler toolchain anyway, and generally a machine with a compiler properly set up should have make too. But in the end all it needs to do is invoke a particular compiler command if a particular file has changed.

I welcome PRs in general, if I am happy with the implementation.

@pewsplosions Hmm yes, 32-bit vs 64-bit might be a problem. Perhaps there should be a way to configure this. I'll change this issue to reflect that and leave it open.