This is sort of stepping into build system territory, which can be quite a can of warms. For instance, what if the C source file requires pkg-config info? Generated headers? Extra, compiler-specific flags?

Python's distutils is a great example of how this can get out of control, at which point people start using their own build systems anyway. For instance, I believe Waf has special support for building Python extensions.

this is for simple cases, for big libraries better to use make in shard post install. example: kostya/http_parser.cr@97e6fad

It's a really cool concept, but as @kirbyfan64 says - it's opening Pandoras box!

@kostya I like this, but I'll check with @waj. I also agree with @kirbyfan64, but for small code where you simply want to compile a small c file it can be useful. For example we could use it in the compiler for the sigfault handler.

We actually had an idea similar to this, but you'd embed the C code in the Crystal source file, somehow. Something like this:

lib Bla
  fun add(x: LibC::Int, y : LibC::Int) : Int32
    <<-C
   // and here comes the C code...
    >>
  end
end

Obviously not exactly like that, because where do you put the #includes. Maybe having it a separate C file is better because you can do things with that file separately (like compile it), can't do that if it's embedded in another source.

I'd really prefer if you'd first post an issue discussing your ideas, but only because we wouldn't like to waste some of your time if we later decide to reject it (although programming in Crystal is probably something fun on it's own 😸)

I'm really surprised and glad that you were able to tweak the compiler to your needs :-)

may be this can be implemented by macro, like ecr_file (and even with auto schema build)

interestingly this might enable some things like http://llvm.org/docs/CoverageMappingFormat.html which need c files.

This could help leverage the llvm for tooling if there where a way to output c files.