Cross-compiling via zig

[jacereda]

This is an attempt to add cross-compiling support (in this case from Linux to Windows, but should be easy to extend to other directions) via zig.

The following command on Linux

./carp.sh --cross x86_64-windows-gnu -b examples/basics.carp

Generated a PE32 executable (haven't tried to execute it though).

[jacereda]

Again, on top of #768, just look at the last commit to see the changes.

[jacereda]

Zig also supports a wasm backend (broken ATM, fixed in current master AFAICS: ziglang/zig#5017), so it should be possible to compile to wasm in the near future.

[hellerve]

Shouldn’t it be possible to do (Project.config "compiler" "zig cc") and (add-cflag "--target=whatever") as well?

EDIT: The cc subcommand might be problematic here. Maybe we could still do something like this and add a macro to make it a little more convenient?

[jacereda]

Yes, but I'm afraid the core needs to be aware of the fact that it's cross-compiling.

[hellerve]

Why is that? So that the run command doesn’t work (which is definitely important)?

[jacereda]

I mean you need to determine things like which headers to include depending on the target platform (not on the host, like we have now).

[hellerve]

Ah, I see: we need to switch from os to target in a lot of places. That makes sense.

[jacereda]

Take a look at windows-only for instance.

[hellerve]

Yeah, I was able to see it when looking at your last two commits in isolation. It’s a little hard to review/see what’s going on for me because of the commits that are pulled in from your dependency PRs (which is of course not your fault).

[jacereda]

Any idea about the Windows build failure?

[hellerve]

That looks like a fluke to me.

[jacereda]

@eriksvedang Can you trigger a rebuild, please?

[eriksvedang]

Retriggered.

Sorry, I haven't taken the time to look through this PR properly yet. My gut reaction is that it's weird to have a built in dependency on something as Esoteric as Zig (despite it being a very cool and promising language, and the cross compiler stuff seems very powerful).

Perhaps a better solution would be better support for configuring the C compilation in great detail. I'm thinking something like configurable settings for all different flags for each compiler, and hooks to do processing of library names, etc, etc.

All in all something that doesn't require tons of changes to the Haskell side every time we want to add more backends, basically. Let me know what you all think?

[jacereda]

What about splitting it in:

• --cc to set the compiler, could be a cross compiler or a native one.
• --target to set the target.

[jacereda]

That would get rid of the zig reference and also remove the tcc reference in #803

[eriksvedang]

That sounds like a great solution!

[jacereda]

I'll also try to rewrite the command line argument parsing. I have something that looks cleaner based on optparse-applicative, hope you don't mind that dependency. I noticed cmdparse is already a dependency, but I'm more familiar with -applicative and IMHO it's a cleaner solution, so I'll also replace the headerparse command line parsing and drop the cmdparse dependency.

[hellerve]

I presonally enjoy optparse-applicative and I think it would be a great solution for argument parsing going forward. Thanks for doing this!

[eriksvedang]

Sounds good.

[eriksvedang]

We can close this now, right? Is there anything that still should be carried over to it's own PR?

[jacereda]

I need to rethink this in the presence of --eval-preload and see how much is needed to support a cross-compiler.

[eriksvedang]

Sounds good.

[eriksvedang]

I'll close this for now, feel free to open a new PR when you have something!