Add macro compile options

[dburnsii]

Compiling Macros within Crystal currently uses system default compile options, not using the options passed to the compiler itself. In order to be compatible with confined build systems like Yocto, the compiler options should be respected across the board, so that even the macros only use libraries explicitly provided by that system if needed.

Concretely, Yocto loads all dependencies (i.e. libraries, binaries, etc.) for it's packages into a folder, and any executable built within the system should only use the provided files, to ensure build portability and repeatability.

[asterite]

I think the intention here is good, but I'm not sure it's correct.

When cross compiling you have macros run in the host system, but the code is generated for a different target system. The flags of the compiler will be relative to the target system, and it's incorrect to set those too for the host system (the macro run code won't compile).

So I think we should only do this if we are not cross-compiling. Basically, cross-compiling and macro run code are not compatible with each other... I think.

About link flags, maybe it's fine to pass those along, I'm not sure.

Is this for macro run?

[jhass]

Yes this is for macro run. Also LGTM, except for skipping the pass when cross compiling, including link flags. So stay as is when in cross compile mode.

[straight-shoota]

This might be fine as a first step, but for cross compilation, target configuration needs to be independent of host configuration. So there needs to be a way to specificy compiler options for the host system explicitly.
This is similar to the discussion in #7196 (comment) ff.

[straight-shoota]

This is a proposal for a proper implementation: We need specific compiler options for the host system (used for macro run). They could be specified as command line arguments (exactly the same as the existing options but with --host prefix). An environment variable CRYSTAL_HOST_OPTS would supplement that.
Unless the compiler does a cross-compile, these options would generally default to the regular compiler options. And you can specify different options explicitly.
For a cross compile, regular compiler options should not be used as defaults for host options.

We probably don't need to implement the whole host options thing right now. A simple and quick fix like this to just use the target options as defaults is a good start.

I don't think assigning link_flags to the program is a good solution, though. It's just one config setting. There are others that would also need to be considered. Instead, the entire compiler config should be attached to the program. That means a compiler instance. It could probably directly be a special instance for host compilation that can be reused. I'm not sure why macro_compile currently creates a new compiler instance every time. As far as I can see, it should be easily reusable.

[jhass]

Maybe --cross-compile should move from build to its own subcommand. Having --host- options sounds good until it's confusing to specify them outside a cross compile. Moving to crystal cross-compile (maybe crystal cross-build for better naming consistency) gives us a nice place to add the --host options only there without polluting crystal build. On crystal cross-build the existing options could even be prefixed with --target- for extra clarity.

More on topic, using default compile options for macro runs when in cross compile mode for the moment sounds good to me, until we solve this holistically. Using above approach or something else.

[straight-shoota]

Closing. The intended use case should be resolved by #9920