On Saturday, 16 December 2023 at 18:59:50 UTC, Johan wrote:

This is actually one (little) benefit, because currently you cannot write a program for Windows that will use some druntime Linux structures for parsing something like net traffic, core dumps, etc. You will need to duplicate Linux (or Posix) structures for that.

This is a meaningless block that has formed historically because it was easier and faster to implement by this way

(At first, I don't see what currently druntime is distributed as ready for cross-compilation bundle. I.e., ldc2 archieve isn't contains druntime binary for Windows, Linux and *BSDs simultaneously, right? In this case we should not change anything particularly much in the config)

As for me, we don't know common this case or not. "Non-standard OS" includes thousands variations of hardware+software from realtime embedded software to modern gaming consoles support or so on.

But it will be simpler to be always at second place (after invincible C and C++) on D support implementation timeline in the event of the appearance of some new (revolutionary, of course) devices or OS inventions. So I think I guess that the impact of such a changes will be great.

ldc2.conf will obtain 3-6 sections (i.e. about ~50 lines total) for common platforms like Linux, Windows and *BSD. Is that too expensive?

On Saturday, 16 December 2023 at 18:59:50 UTC, Johan wrote:

I want to explain more here, so that it does not seem like an inability to accept another point of view

My reasoning are as follows:

It is need to switch source files (partially) by some way. It's possible, apparently, by 3 convient ways:

1. By adding public import into modules (as you proposed in message above, and I answered why this will not work well)
2. By adding script witch switches SRCS and COPY lists (my solution)
3. By patching compilers: adding some CLI switches that will force all compilers(!) to switch modules directories or something like. It seems to me, no one will like such approach

So, only one realistic solution is possible

And, after all, if proposed approach will not work, i.e., if time shows that this is terrible to maintain all theese modules sources in config/, then we can use a trivial script to return everything to its ~original state. (Even better because the script will not forget to add static assert "fuse" for non-supported version(..))

On Saturday, 16 December 2023 at 19:42:43 UTC, Denis Feklushkin wrote:

If it's meaningless, it can be removed today without your big file change. Can it?

For cross-compilation, you don't need druntime binaries. The binaries are only needed for linking. But if linking with druntime/phobos is needed, then LDC has a specific tool to make it easier for users to build druntime+phobos for a different target platform. And then you just specify the location of those binaries on the cmdline. Yes, this can be simplified for continued use by editing ldc2.conf, but it is not required to do so; nor is it needed to have a separate druntime source tree stored somewhere else.

You make it sound as if it is currently impossible to implement druntime for linux, Apple, Windows, Solaris, OpenBSD, NetBSD, FreeBSD, DragonFly, Android, ... x86, x86_64, arm32, aarch64, riscv, ... Yet, the implementation for all these exists.

Please show us the PR where you fix LDC, Dub, and GDC for the problems you are introducing.

Thanks,
Johan

On Sunday, 17 December 2023 at 09:37:33 UTC, Johan wrote:

*Tiny file change

Only in dynamic linking mode, yes

For example, no one is surprised by the different Linux kernel headers packages, coresponding to a different kernel binaries, but derrived from one kernel source tree

Also, we can generate and provide import/ dirs for a few platforms (what you mentioned below) simultaneously if it will be decided as more convient

Sorry, but this is obvious demagoguery - matrix of 3 RTOSes, 3 CPU architectures and 3 LIBCs easily give us 27 platforms in this terms

What's wrong with DUB?

Sorry, but now your turn to propose solution other than these 3 listed in the previous message

On Sunday, 17 December 2023 at 11:00:02 UTC, Denis Feklushkin wrote:

Yes indeed. And there will be more breakage. Cross-compilation on godbolt.org will also break.

-Johan

On Sunday, 17 December 2023 at 12:13:57 UTC, Johan wrote:

Nothing will be broken - https://github.com/dlang/dmd/pull/15887#issuecomment-1890961483

2 All:

Recently latest issue that was preventing tests from passing on low-end MCU-style platforms has been resolved (Bugzilla 15504)

I suggest us think again about what we are losing now

This is a whole new World that is hidden from us (i.e., from developers who use Windows-Linux-Mac) only because devs have to go through hell to get a LED blinking on D. We lose good synergy effect. Newcomers with a different expierence will pass through our low-level code to implement D support for a very different platforms. Community will be able to very quickly implement D support of the mostest inventions such as virtual reality helmets (if is this still considered as innovation), specialised computing systems (for which now is only C and Fortran) and for all modern stuff. Also, to write on D for Sega Genesis (Megadrive 2) or for Playdate - this is just cool!