• Brian (21/21) Oct 02 2021 Hello all --
• IGotD- (12/19) Oct 10 2021 No, there isn't such rule. DRuntime OS dependent code is
• Walter Bright (7/7) Nov 28 2021 The general idea for OS-specific files is to *not* attempt to merge them...

Brian <bcallah openbsd.org> writes:

Hello all --

I posted a DRuntime PR 
(https://github.com/dlang/druntime/pull/3577) syncing OpenBSD 
dlfcn.h defines.

I noticed that some of this dlfcn information is both in the 
OS-specific dlfcn.d file and the POSIX dlfcn.d file. Worse still, 
the OpenBSD-specific version of dlfcn.d is markedly different 
than the FreeBSD and NetBSD specific versions of dlfcn.d. The 
FreeBSD and NetBSD specific versions of dlfcn.d duplicate 
information that appears in the POSIX dlfcn.d file (e.g., the 
Dl_info struct) whereas the OpenBSD version does not have (as 
much) duplication of effort.

That leads to a few questions...
1. Is there some sort of standard rule for which duplicated 
effort wins?
2. Is deduplication desirable?
3. (and most immediately important) Should I be keeping my PR 
as-is or should I make the OpenBSD dlfcn.d look more like the 
FreeBSD and NetBSD versions?

Thanks.

~Brian

IGotD- <nise nise.com> writes:

On Saturday, 2 October 2021 at 18:25:16 UTC, Brian wrote:
 That leads to a few questions...
 1. Is there some sort of standard rule for which duplicated 
 effort wins?

No, there isn't such rule. DRuntime OS dependent code is 
currently chaotic. I posted previously that I wanted an API for 
the OS dependent stuff and OS dependent code must be in their own 
files.

 2. Is deduplication desirable?

No, it isn't.

 3. (and most immediately important) Should I be keeping my PR 
 as-is or should I make the OpenBSD dlfcn.d look more like the 
 FreeBSD and NetBSD versions?

I think we should use a generic version as much possible. This 
means that each OS can have it's own dlfcn.d file but if POSIX 
can be used this file should include the generic POSIX dlfcn.d 
file.

We can have multiple dlfcn.d files but implementation should be 
moved to the generic one as much as possible.

Walter Bright <newshound2 digitalmars.com> writes:

The general idea for OS-specific files is to *not* attempt to merge them.

The problem with merging them, is when someone doing a PR for, say, Linux, 
changes something in the common part, they can (and inevitably will) silently 
and disastrously break some other OS.

Hence, PRs for Linux headers should *only* affect Linux systems.

This works because Linux headers are never used by FreeBSD systems, even if
they 
have identical sections.