Crystal: Moving the LibC - support new bindings

[j8r]

The idea is to have a Crystal equivalent of https://golang.org/pkg/syscall/#Statfs_t to retrieve block informations relative to a directory (thus the disk).

My use case is to have the disk usage of the partitions.

[j8r]

The struct involved is LibC::Statfs - what will be its place regarding to File::Info (which is based on LibC::Stat on UN*Xes)?

[straight-shoota]

Why don't you just add the libc bindings in your shard? Your use cases requires zero changes to the stdlib.

[j8r]

Because it's better to have projects that shares reusable code instead of having duplications.

[j8r]

I wish Crystal supports better the libc, and compete with the Rust's and Go's stdlib in the system side.
The solutions are to create https://github.com/crystal-lang/libc like Rust do (and integrate it with git submodules, git subtree or as a shard) or to keep it as a Go's syscall fashion.
Furthermore @RX14 suggested to move LibC to Crystal::LibC .

[j8r]

A dedicated repository for libc bindings is created.

[straight-shoota]

What is it good for? If a shard uses a C binding (be it libc or anything else), I'd rather just declare the bindings in that shard instead of relying on another one.

[ysbaddaden]

Support for many targets.

Supporting a C binding to a library is easy. Supporting a C binding for a libc call... I wish you good luck.

[RX14]

We'll see how this space matures then maybe make some bindings official once there's something well-used.

Before then, perhaps we should move LibC to Crystal::LibC to make it explicit that these are just bindings for the stdlib and they're private. Thoughts?

[ysbaddaden]

No. It would just be more confusing.

[RX14]

@ysbaddaden how so?

[j8r]

IMO Rust has done this quite right by creating a separate crate in its own repository, and integrating it in the main Rust repository with git submodules (even if I prefer git subtree).

[ysbaddaden]

@RX14 It's already bad enough that we have named definitions such as LibC, LibEvent or LibSSL that are purely virtual, because in the end a fun is a fun wherever it's defined —there can only be one C symbol, and all definitions must match.

Introducing namespaced LibC definitions would push for even more confusion...

IMHO all external symbols should be defined under LibC and that's it (no LibSSL, LibLLVM, ...) —this is what my c2cr binding generator assumes.

@j8r good luck with the shard! It would be fantastic to have, but hard and long and damn error prone... (see my abandoned POSIX project for instance).

[asterite]

@j8r I still don't understand why you don't create a statsfs shard and be done with this discussion, and why not having that specific binding to the function in the standard library bothers you so much. Otherwise, send a PR with those specific C function bindings and a proper wrapper, and someone will surely accept it. The standard library uses C bindings for the standard library. Having more, undocumented, unstable functions so that other shards can use them is not very productive in my opinion. Plus generating those bindings is really complex, as @ysbaddaden points out.

Why do we need this issue open?

[j8r]

@asterite this isn't only about statfs, but about all other native functions provided by various systems.
They doesn't always have there place in the language itself, with wrappers, objects, interfaces etc. — some are really specific to the underlying system.
Creating a shard for this purpose fits well the role.

[ysbaddaden]

Let's close.

Having a libc shard is a good idea. It's better to centralize definitions for many targets, rather than having each and every shard defining a few non-portable definitions that they need. These definitions could even clash with each other, if they happen to use the same underlying libc calls, but named structs or unions differently for example.

Thought IMHO having definitions generated on-the-fly using libclang would be the definitive solution (still allowing some manual definitions to avoid a few quirks).

[j8r]

Totally agree @ysbaddaden . I was just looking at your project clang.cr, and will send you some PRs (LLVM6, split of c2cr).
There is a need for wider LibC support, and the on-the-fly solution can be good if done right - working on it.

[RX14]

@ysbaddaden but that still doesn't stop people treating the stdlib's LibC as if it's a somewhat stable surface, I think moving to Crystal::LibC would better discourage people outside the stdlib from using it.

[j8r]

@ysbaddaden following your work with c2cr, I've modified the libc project to autobind to generate bindings (including libc), with libclang