Implement host_flag? macro method, not affected by cross-compilation

[oprypin]

The flag? macro tells you information about the target architecture, but one may need to run a command at compile time (so on the host), and it would be a different command depending on which OS it is.

Example:

diff --git a/src/compiler/crystal/config.cr b/src/compiler/crystal/config.cr
index 8b756583e..38215b7c8 100644
--- a/src/compiler/crystal/config.cr
+++ b/src/compiler/crystal/config.cr
@@ -32,7 +32,9 @@ module Crystal
     end
 
     def self.date
-      time = {{ (env("SOURCE_DATE_EPOCH") || `date +%s`).to_i }}
+      time = {{ (env("SOURCE_DATE_EPOCH") || (
+                  host_flag?(:win32) ? `powershell Get-Date -Millisecond 0 -UFormat %s` : `date +%s`
+                )).to_i }}
       Time.unix(time).to_s("%Y-%m-%d")
     end

[asterite]

This makes me wonder if we should be computing all of those things with macros.

That said, this needs to also be added to the macro docs (search for def flag? and you'll find it).

[oprypin]

The bad thing here isn't really the macros but the shelling out :)
Each instance of that is technical debt, and we'll be scratching our heads now that Windows is relevant.
Definitely the most fun instance of this is ldflags: "`stuff`"

crystal/src/llvm/lib_llvm.cr

Line 10 in f4b01c8

@[Link(ldflags: "`{{LibLLVM::LLVM_CONFIG.id}} --libs --system-libs --ldflags --link-static 2> /dev/null`")]

See, no macros there :)

[oprypin]

needs to also be added to the macro docs

I realized it later, but that also made me think, maybe we should keep it undocumented for now. I don't know if we'll want to keep it, in this shape, or at all.

First off, I'm thinking to resolve that particular example above with macro run instead.

Then I also noticed that some important use cases are missing with this data representation. E.g. what if I want to check whether host OS differs from target OS? Should I go through every possible pair of flags and check if they're not equal?

So yeah, I'm mostly hedging my bets at this point, because this will need a Crystal release before it can be used.

[waj]

@oprypin could you please fix the conflict so we can merge this? Thanks!

[straight-shoota]

I've looked at the previous discussion in #7196 which also touched this. Seems this is on par with what we considered back then 👍
Still have two suggestions to improve this PR (but it's not a necessity).

[straight-shoota]

I'd also suggest to rename Config.default_target to Config.host_target because that's what it is.

[oprypin]

OK, didn't turn out too big.

[oprypin]

Woops, pushed a bad commit previously, should be good now