Add a conditional compilation system to allow features available only on some platforms.

[carllerche]

I removed a number of bindings that were not generally portable in order to get everything compiling on Rust 1.0 beta. These should be brought back.

[kamalmarhubi]

Thinking about #264 (using definitions from libc), we may want our own analog of the sys module pattern. Right now it's hard to track down where items come in because the cfg attrs are all over the place. @arcnmx you have a recently opened RFC on a related topic. Thoughts?

[arcnmx]

Well, I'd say it's an unrelated issue in regards to my proposal toward libstd, which is more about defining an abstraction layer over the OS for libstd to use. libstd has a lot of ifdef/else/elif/etc going on where different implementations are used depending on the platform. nix seems more all-or-nothing; everything is in the right place, just cfg'd out if something doesn't apply to a given platform.

That said, moving all the mod ffi stuff into another layer under nix with the maybe-goal of eventually migrating it all into libc could potentially be a good idea. It would let us make it a public separate nix-sys crate too that only defines the raw C API.

it's hard to track down where items come in because the cfg attrs are all over the place

Not sure I understand what you mean by that, what's hard? Most items are cfg'd out directly at their definition point AFAIR

[kamalmarhubi]

Ah I see. Maybe I actually meant a file layout more like libc's then. A way to have a hierarchy of related systems, so that there's a clear place to put definitions. Then we can use conditional module imports instead of conditional definitions. It seems like less mental effort to me in terms of where to put things.

[kamalmarhubi]

Here's the section describing it in the libc RFC: https://github.com/alexcrichton/rfcs/blob/pomote-libc/text/0000-promote-libc.md#internal-structure

[fiveop]

Currently, I am against this change. libc has this structure and it fits with its concept. For us, I do not see the advantage, but am rather afraid it would lead to a lot of code duplication. This is the case in libc, and I do not see a way around that there. However, we can use that libc hides that fact, by using their constants and function declarations. This would leave us with configuring a few functions and certain constants in bitflags and enums in and out depending on platform.

[kamalmarhubi]

This makes sense. We should get fully onto libc definitions (#264) first, then see what it looks like.

[Susurrus]

I think the current consensus is to defer on this. Should I close this issue and it can be revisited if necessary?