On 2017-11-03 03:43, Jonathan M Davis wrote:
So, I fully expect that there are times when being able to version the
source code based on the OS version (or the libc version if you're talking
about Linux) would be needed. However, I don't know if it's needed often
enough for the compiler to directly support it rather than using custom
version specifiers for those code bases that do. Technically, I think that
the versioning that they do in C/C++ for this sort of thing with #includes
is more or less equivalent to using custom version specifiers rather than
actually doing anything special with the compiler.
Regardless, it would be nice if we could avoid the need to statically
version any code in dmd, druntime, or Phobos based on OS version.
I don't know all the details, just throwing some ideas out there:
* macOS went through a similar transition, perhaps have a look at how
Apple did that. There some information here [1], scroll down to the
documentation for the _DARWIN_FEATURE_64_BIT_INODE macro
* Fully statically link the binaries, including the C standard library.
Might work assuming the kernel did not change
* Do something similar to what AppImage [2] is doing on Linux. AppImage
works by creating a binary with an executable header and a disk image
that holds the payload. In the case of AppImage the payload would be the
application including all the files necessary to run it. Perhaps we
could instead build something like universal binaries on macOS. Embed
two separate executables and run one of the depending on the current system
[1]
https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/stat.2.html
[2] https://appimage.org
--
/Jacob Carlborg
