On Friday, 1 December 2023 at 05:29:31 UTC, Denis Feklushkin wrote:

x86_64,posix,osx

x86_64-posix-osx

Thank you, now I have a better understanding what a tag is. Correct me if I'm wrong so these tags are like "feature defines" similarly to a boatload of C defines that you must define for certain C-libraries. Will these tags eventually become version identifiers inside the code? Also one question if the tags are visible inside the D code or just outside the code in the build system?

We have OS/API specific code in druntime but also generic code that can be shared by all OSes. What I was looking for is an explanation where this generic code should located. Will it be like it is right now and you break out the OS specific code and put it in druntime/config/? For example we can make the code in druntime/src/core/thread/osthread.d (which is absolutely horrible) and start to define what is OS independent, leave it inside osthread.d and then put OS dependent stuff in the new files?

On Friday, 1 December 2023 at 12:53:55 UTC, IGotD- wrote:

No, if I correctly understand this "C features defines" concept

No

Tags are visible only for druntime build system

Yes, this is correct

Good example is event.d - proposed PR splits it into 3 files: Posix and Windows implementations and also shared between OSes module druntime/src/core/internal/event_tests.d, containing mandatory unittests which are common for all Event implementations

Specifically for osthread.d:

At first step I propose some small refactoring for osthread.d: it is need to move code shared for all OSes into "core.thread.threadbase" module. As I remember, community wanted to do this for a long time but there was no reason to begin this process.

Then we can move osthread.d into confing/ and also split it into Windows and non-Windows versions

All this can be done gradually. We don't even forced to split osthread.d at first stages if we afraid to broke something.

On Saturday, 2 December 2023 at 08:10:57 UTC, Denis Feklushkin wrote:

The tags, how are they injected into the build system? Keep in mind that we have several types of build systems in the D project. I think DMD uses traditional make files. LDC uses Cmake.

Are they going to be a separate file where you just define variables for build system?

On Saturday, 2 December 2023 at 12:30:31 UTC, IGotD- wrote:

Tags defined in the build script. For DMD, druntime/posix.mak:

# TODO: implement tags table
ifeq ($(MODEL), 64)
	ARCH=x86_64
else
	ARCH=x86
endif

ifeq ($(OS), Win_64)
	# Tags order doesn't matter
	TAGS:=windows,default,$(ARCH)
else
	TAGS:=$(ARCH),posix,$(OS),default
endif

In the future it will be trivial to add environment variable or option for manual setting tags and dir(s) to expand ability of builds for various platforms

Yes. (+I use Meson for druntime builds for experimental embedded targets)

ldc/runtime/CMakeLists.txt contains:

# only include core/sys/ modules matching the platform
file(GLOB_RECURSE DRUNTIME_D_BIONIC  ${RUNTIME_DIR}/src/core/sys/bionic/*.d)
file(GLOB_RECURSE DRUNTIME_D_DARWIN  ${RUNTIME_DIR}/src/core/sys/darwin/*.d)
file(GLOB_RECURSE DRUNTIME_D_DRAGONFLYBSD ${RUNTIME_DIR}/src/core/sys/dragonflybsd/*.d)

I don't know CMake deeply, but it looks like it is not too difficult to adopt proposed changes into LDC build facility

Most likely, this will not be done due to the fact that all build systems are too different (Although I just found similar idea in my comment "TODO: implement tags table")

On Saturday, 2 December 2023 at 14:02:07 UTC, Denis Feklushkin wrote:

Everything is almost ready: https://github.com/dlang/dmd/pull/15822

Also, PR description changed and expanded

There is only one small blocker: https://github.com/dlang/dmd/pull/15880

I'm really looking forward to your feedback!

On Saturday, 2 December 2023 at 08:10:57 UTC, Denis Feklushkin wrote:

How is this going to work for cross-compilation with one compiler druntime? LDC is a cross-compiler and uses the same source files for any target. A single LDC installation must be able to compile to any target platform, i.e. with a single druntime installation. (target-dependent copying of files by the compiler build system does not fulfill that requirement)
To me, it sounds like your changes make separate druntime installations per target. This is not acceptable for LDC. But perhaps I misunderstood your changes.

-Johan

On Wednesday, 13 December 2023 at 17:43:06 UTC, Johan wrote:

With ldc2 we can switch druntime by using custom .conf file ("--conf=" option).
I successfully use this for my custom druntime builds

Yes, you are right

More precise: same as we already(?) provide separate druntime binaries for each target (i.e., Linux, Windows, etc) I propose to provide a separate include dir for each of these druntime binary

It seems to me, for proposed druntime switching, syntax of /etc/ldc2.conf already contains all necessary things?

On Saturday, 16 December 2023 at 13:04:27 UTC, Denis Feklushkin wrote:

I remain my stance that this is unacceptable. You are forcing a big change on a system that already works, without a real benefit.
Yes, it is possible to work around the problems introduced by you by writing .conf entries for every platform, but that is extra burden on package maintainers that they currently don't need to do.

Simply use version in source files, and all is good (like now). Separate files do not require completely separate source trees. You can have a file with something like:

version (A) {
  public import foo_A;
} else version (B) {
  public import foo_B;
...

-Johan

On Saturday, 16 December 2023 at 18:09:57 UTC, Johan wrote:

Make sure what you read benefits list:
https://github.com/dlang/dmd/pull/15822#issue-1996484133

Also it constains considerations about why this approahch will not work ("Another options to solve problem is more painful"):

version (A) {
  public import foo_A;
} else version (B) {
  public import foo_B;
...

On Saturday, 16 December 2023 at 18:44:00 UTC, Denis Feklushkin wrote:

Much of your list are not benefits, just removing things from the source code that you find "ugly" I guess. For example, removing version (Linux): is not a benefit; it's just developer taste, with no benefit for the user.

I understand that for you currently the situation is not nice. But it is not a good solution to make life good for you, and make it worse for the status quo. A custom druntime or non-standard OS is not a very common case.

-Johan