@MikaelUrankar are you still around? could you help us add missing parts for aarch64-freebsd ?

Yes, what's needed?

could you generate platform-specific files on https://github.com/jnr/jnr-constants and create a PR to that repo?

rake regen:platform
rake regen:lplatform

aarch64-freebsd isn't supported yet and this would be very helpful.

I can add syslog constants manually based on your previous PR or use jnr/jnr-constants#99 as a baseline.

thanks!

Done, I hope it's ok.

great thanks!

I've merged the jnr-constants PR. Anything else needed before releasing that and updating JRuby?

nothing else, this PR is ready once jnr-constants are released

Today's the day.

@ahorek If you merge or rebase from master this will pick up the new jnr-constants.

@headius thanks for the reminder, could you merge up jruby-9.2 branch into master? #6911 isn't there yet

@ahorek I merged 9.2 yesterday so everything should be there. We just moved the 3.0 work to master (red in CI 🤷‍♂️) and master to jruby-9.3, so I retargeted this PR against 9.3.

Bleh sorry you are right, I had not merged JNR stuff fully yet. I am fixing that now.

thanks @headius

hmm, fake constants are actually considered as defined which is something we don't want on Windows... anyway, CI looks good now.

I am on the fence about whether they should appear to be defined. If they are close enough but we don't have generated values for all of them it would be nice to be able to use them but does that mean they're defined or not? Defined is really intended to indicate this constant does not and will never exist on this platform

I originally wanted to do something like this:

if fake_platform?
  raise "unsupported platform" # or do nothing
else
  define_available_constants # we can rely on that these constants are usable
end

we know Windows cannot be supported, but without an additional platform check in JRuby, we do define all possible (but fake) constants which isn't desirable for this use case.

Windows is a particular challenge, but the fake constants were originally envisioned to provide a full set of constants when we were emulating native behavior. It allows us to define the constants with reasonable values and use those constants in pure-Java versions of these APIs. So by that definition, the "fake platform" really is its own platform that defines all constants.

Perhaps where it went off the rails is that we are using the fake values also on platforms where we do not have generated constants, and end up defining all of them whether they are relevant to the platform or not.

I'm not sure I understand your example. Would you have us error on platforms where we don't have accurate generated constants?

Maybe we should open this as an issue on jnr-constants and have the discussion there, so we don't lose track of it.