What is the FreeBSD situation?
Jonathan M Davis
newsgroup.d at jmdavisprog.com
Thu Nov 2 21:25:19 UTC 2017
On Thursday, November 02, 2017 13:46:11 Walter Bright via Digitalmars-d
wrote:
> On 11/1/2017 10:11 PM, Jonathan M Davis wrote:
> > But we
> > don't currently have a way to version code for a particular version of
> > FreeBSD even if we wanted to.
>
> The FreeBSD version can be detected at runtime, and different code
> executed.
Sure, but you can't actually compile different code based on the FreeBSD
version, and if a type or function API changes, then that doesn't work.
Wouldn't you get a linker error for the stuff that isn't actually defined on
the C side of things? If so, then you can't really provide both the old and
new versions of a function or type and switch between code that uses one or
the other based on the version of the OS at runtime. You'd have to be able
to have the source code differ depending on the FreeBSD version.
Depending on what was done with the compatibility layer for the 64-bit inode
stuff, we may be able to do something in this case to choose which to use
based on the version of the OS at runtime, because you'd have both the
direct API and the compatibility API to use and thus there are different
symbols to link against, but in the general case, if an API is simply
updated, then you only have one version to link against. So, while we may be
able to deal with this particular issue with something that makes the choice
at runtime, I don't see how that would work in general any time that there's
a breaking API change. Any time that happens, we'd need to be able to
statically differentiate which version of FreeBSD we'd be compiling for.
And that may not actually ever come up, since it's not like the FreeBSD
folks change APIs for the fun of it, but it still looks to me like not being
able to version the source code based on the version of FreeBSD your
compiling for is potentially a showstopper for having code work with
multiple versions of FreeBSD. I think that we're more likely to get away
with it with dmd, druntime, and Phobos, because we mostly use POSIX APIs,
which they aren't going to be changing much, but if you're dealing with
something that isn't POSIX, then the odds are that it would matter more.
In such a case, you'd probably be forced to either provide different
versions of a module depending on the OS version, and have the build system
differentiate for you, or you'd have to provide custom version identifiers
as part of the build so that the code could be versioned appropriately.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list