Support FreeBSD 12 (64-bit inodes)

[myfreeweb]

(also we're unknown now instead of portbld, so I added a symlink there)

THANK YOU for simply splitting the llvm target on - and shoving everything into flags. Rust currently drops the version number from targets and it's painful.

// Ideally, this would use a version comparison >= 12.0, but this is fine for now.

[ararslan]

Very exciting! Would it be possible to enable 11.1 or is there something specific to current that's required?

[ararslan]

Very exciting! Would it be possible to enable 11.1 or is there something specific to current that's required?

[myfreeweb]

11.1 worked as is. On 12 it was broken because of the inode/dirent/stat changes in the kernel. This fix uses the new structs on 12.

[myfreeweb]

11.1 worked as is. On 12 it was broken because of the inode/dirent/stat changes in the kernel. This fix uses the new structs on 12.

[ararslan]

Ah, great. Sorry for the noise then.

[ararslan]

Ah, great. Sorry for the noise then.

[RX14]

This is fine for now, but we should probably think a bit more about how to handle the BSDs' libc in the future.

[ysbaddaden]

FreeBSD 12.0 is -CURRENT hence not released, so there is no need to rush and merge.

C bindings should be considered as automatically generated. Starting to put flags to support one or another version is unexpected. Also, using freebsd12.0 will break on point releases (12.1) and next major releases (13.0).

Maybe we can introduce flags without the leading .x to target versions more broadly —I don't except point releases to break ABI... but maybe I'm wrong? Anyway we should reverse to check for freebsd10 and freebsd11 (supported versions) to rely on legacy structs, but use the new structs otherwise?

[ysbaddaden]

FreeBSD 12.0 is -CURRENT hence not released, so there is no need to rush and merge.

C bindings should be considered as automatically generated. Starting to put flags to support one or another version is unexpected. Also, using freebsd12.0 will break on point releases (12.1) and next major releases (13.0).

Maybe we can introduce flags without the leading .x to target versions more broadly —I don't except point releases to break ABI... but maybe I'm wrong? Anyway we should reverse to check for freebsd10 and freebsd11 (supported versions) to rely on legacy structs, but use the new structs otherwise?

[myfreeweb]

Yeah, that's why I said

Ideally, this would use a version comparison >= 12.0

I guess I should work on that…

Point releases don't break ABI, you're not wrong.

[myfreeweb]

Yeah, that's why I said

Ideally, this would use a version comparison >= 12.0

I guess I should work on that…

Point releases don't break ABI, you're not wrong.

[RX14]

@ysbaddaden you can't consider the C bindings as automatically generated unless they are automatically generated. I never got the generator to work and contributors are unlikely to do the same, unless the whole generation process comes down to a simple, fairly portable command. I doubt many of the recent lib_c changes were not manually done.

[RX14]

@ysbaddaden you can't consider the C bindings as automatically generated unless they are automatically generated. I never got the generator to work and contributors are unlikely to do the same, unless the whole generation process comes down to a simple, fairly portable command. I doubt many of the recent lib_c changes were not manually done.

[ysbaddaden]

I never said we can't maintain C bindings manually, but to keep in mind they should be auto-generated and will eventually be (since we can't rely on fixed sets, as this issue outlines) to help avoid changes that would prevent this.

I don't understand how nobody got the generator working. Yes, cross compiling headers for a foreign platform is tricky (because local compiler & system headers get in the way), but generating bindings for the current platform is a mere shards install ; make crystal (ok, it broke with crystal 0.24 because of yaml changes).

[ysbaddaden]

I never said we can't maintain C bindings manually, but to keep in mind they should be auto-generated and will eventually be (since we can't rely on fixed sets, as this issue outlines) to help avoid changes that would prevent this.

I don't understand how nobody got the generator working. Yes, cross compiling headers for a foreign platform is tricky (because local compiler & system headers get in the way), but generating bindings for the current platform is a mere shards install ; make crystal (ok, it broke with crystal 0.24 because of yaml changes).

[myfreeweb]

This issue also means that autogeneration would only generate code for one OS version, unless you make it read headers from multiple versions.

[myfreeweb]

This issue also means that autogeneration would only generate code for one OS version, unless you make it read headers from multiple versions.

[RX14]

@ysbaddaden the benefits of automation here are consistency and reproducibility. As people have demonstrated with their PRs, doing it manually is easier than using posix bindgen so ease of use certainly is not what was achieved. As soon as you edit it by hand all of those benefits are lost and to me it's as good as manually generated. Unless there's a single command to generate these bindings for all platforms we support automatically and they're actually kept in sync, all posix is good for was the chore of writing lib_c in the first place.

[RX14]

@ysbaddaden the benefits of automation here are consistency and reproducibility. As people have demonstrated with their PRs, doing it manually is easier than using posix bindgen so ease of use certainly is not what was achieved. As soon as you edit it by hand all of those benefits are lost and to me it's as good as manually generated. Unless there's a single command to generate these bindings for all platforms we support automatically and they're actually kept in sync, all posix is good for was the chore of writing lib_c in the first place.

[asterite]

No need to use symbol, you can just write:

{% if flag?("freebsd12.0") %}

[straight-shoota]

Hm, now this was merged with symbol...?

[asterite]

It was just a note, not super necessary to make it work. There's also no difference regarding performance or anything, just style.