Circular dependency when emerging dmd-2.071

[Kiiyya]

I get this error:

(dev-lang/dmd-2.071.0:2.071/2.071::dlang, ebuild scheduled for merge) depends on
 (dev-lang/dmd-2.071.0:2.071/2.071::dlang, ebuild scheduled for merge) (buildtime_slot_op)

And the suggestion that it might be possible to break it by applying a use flag change like -dmd-2_071 +ldc2-0_17, which I did, which only leads to more errors, including that the dmd-2_071 use flag is required.)

(I am not good at this. If need be, just close it and forget this, sorry)

[mleise]

You were doing it right. This is how it looks like for me:

[ebuild  N    ] dev-lang/ldc2-0.17.1-r1
[ebuild  N    ] dev-lang/dmd-2.071.0  USE="doc examples ldc2-0_17 tools -dmd-2_067 -dmd-2_068 -dmd-2_069 -dmd-2_070 -dmd-2_071 -ldc2-0_16 -static-libs" ABI_X86="32 (64)" 
[ebuild  N    ] dev-util/dlang-tools-2.071.1  USE="ddemangle detab dmd-2_071 dustmite rdmd" 

Once DMD 2.071 is installed you can recompile it with itself if you want. You can also pick dmd-2_067, which is the last version of DMD that doesn't require an installed D compiler to bootstrap and is faster to install than LLVM+LDC2.

[ff2000]

I just ran into the same problem. Wouldn't it be better to simply bootstrap dmd itself without all those fancy USE-Flags? If the user wants to install dmd himself he most likely won't care which D-compiler is used to get the most recent dmd running, At least I did not even think about setting USE=ldc_* when I just wanted to install dmd. IMHO it would be even possible to download and use a precompiled dmd in order to minimize compile time. With the current approach I need to install a compiler just to uninstall it again... Even worse the user currently has to know WHY this weird dependency hell just came upon him, and that it can be easily solved by sticking to dmd-2.067 as it is the last one which does not need a working D compiler. Is there a chance to at least produce an error message that explains the issue?

[mleise]

Wouldn't it be better to simply bootstrap dmd itself without all those fancy USE-Flags?

It's an option, but not unanimously the better one, to drop the flags.

If the user wants to install dmd himself he most likely won't care which D-compiler is used to get the most recent dmd running, At least I did not even think about setting USE=ldc_* when I just wanted to install dmd.

Please, by any means use the ldc_* flags. LDC has much better optimization capabilities and your resulting DMD compiler will run quite a bit faster, which is the main strength of DMD aside from providing the most up-to-date language implementation.

IMHO it would be even possible to download and use a precompiled dmd in order to minimize compile time.

Actually when compilation of DMD starts, there is already a precompiled executable lying around in the build directory. The earliest encounters of DMD on Gentoo were all dmd-bin packages that just extracted binary blobs. But that was when the backend code wasn't open sourced and it was plain impossible to do compile all of DMD from sources. Where the source code is open, you'll typically only find those binary packages for ebuilds with excessive compile times, such as Firefox or Open-/LibreOffice. Two benefits of that are that you can now apply user patches (https://wiki.gentoo.org/wiki//etc/portage/patches#Adding_user_patches) and have the choice to use DMD or LDC (and GCC later on) to compile DMD.

With the current approach I need to install a compiler just to uninstall it again...

Hey! You could say the same of cmake, ant, ninja and all the other dependencies that you no longer need, once the package that needs them as build dependency is merged. To take it to extremes, I could claim that I installed GCC just to uninstall it again once all C/C++ packages are installed as I don't really need it for my daily work. :grin:

Even worse the user currently has to know WHY this weird dependency hell just came upon him, and that it can be easily solved by sticking to dmd-2.067 as it is the last one which does not need a working D compiler.

The rationale is on the Wiki. (Top result when you search the web for "gentoo dlang".) https://wiki.gentoo.org/wiki/Dlang#DMD_depends_on_itself I should mention that 2.067 is the last version that doesn't require an existing D compiler for any of its build steps. 2.068 is already compiling a D helper script.

Is there a chance to at least produce an error message that explains the issue?

The circular dependency is detected very early. Typical sanity checks such as "too little disk space to compile libreoffice" come after dependency resolution. I'm afraid any warning message that shows earlier than that could also show up in unrelated situations where portage look at dependencies.

I completely understand the grief. Dlang is defined by its reference compiler which always features the most up do date language implementation and there is a binary package up for download that just works. But I have to acknowledge that Gentoo is a source distribution and that Dlang compilers can be compiled by any other Dlang compiler with language version >=2.067. For now the choice is between DMD and LDC, but imagine for a moment that GDC had more success in getting merged with GCC and was at 2.067 at least. Then we'd probably agree, that GCC should be the default compiler for DMD as it is for any other "native" package in the system. But for now the choice is not so clear. In fact LDC is probably considered the most advanced Dlang compiler and the best default. I just noticed - thanks to your comment - that it still lacks the dmd-* and ldc-* use flags! It currently picks up whatever D compiler is installed and errors out if none is available.

I could try and make dmd-2_067 the default use flag for DMD ebuilds and ldc2-0_16 (uses 2.067) the default for LDC ebuilds. I.e. get it working by default and use as few intermediate steps as possible. Would that make sense? Ultimately, in all fairness, you also can't install GCC without a moderately recent C compiler on your system.

Another option is to maintain an additional dmd-bin ebuild for convenience.

And yet another one is to offer an additional use-flag like "selfhost" or "bootstrap" that uses the precompiled dmd executable in the Linux package to build the package. That option is also not available for LDC.

[ff2000]

Please, by any means use the ldc_* flags. LDC has much better optimization capabilities and your resulting DMD compiler will run quite a bit faster, which is the main strength of DMD aside from providing the most up-to-date language implementation.

Not possible because I run llvm-3.9.0 and there is no compatible ldc in the overlay. ldc-0.17.2 with compatibility also was released just 12 days ago. I also had ldc block llvm updates the last time I played with D.

Hey! You could say the same of cmake, ant, ninja and all the other dependencies that you no longer need, once the package that needs them as build dependency is merged. To take it to extremes, I could claim that I installed GCC just to uninstall it again once all C/C++ packages are installed as I don't really need it for my daily work. :grin:

As we are talking about Gentoo here: cmake is used everytime I do an update here. As is gcc. Furthermore gcc also ships libstdc++.so and uninstalling that would break everything ;) The issue here is that I need to install (and compile) two compilers to get the one I want running.

I could try and make dmd-2_067 the default use flag for DMD ebuilds and ldc2-0_16 (uses 2.067) the default for LDC ebuilds. I.e. get it working by default and use as few intermediate steps as possible. Would that make sense?

Another option is to maintain an additional dmd-bin ebuild for convenience.

And yet another one is to offer an additional use-flag like "selfhost" or "bootstrap" that uses the precompiled dmd executable in the Linux package to build the package. That option is also not available for LDC.

All three options sound OK. Though I wonder if we really need such finegrained choice. Wouldn't it be enough to just offer USE="dmd-2_067 dmd ldc2" and in case of dmd and ldc2 just use the most recent available version? selfhost IMHO sounds even better, probably enable it by default and tell the user in pkg_setup that he can disable it and set ldc2 to get a more performant compiler? This IMHO would make it easier for the user to get his fingers on D in Gentoo.

Ultimately, in all fairness, you also can't install GCC without a moderately recent C compiler on your system.

Again, we are in Gentoo here. And if you skip updates for such a long time that your compiler isn't recent enough to get the latest available gcc compiled you most likely have way bigger problems (e.g. with python and portage itself).

[mleise]

Dmd is now installable out of the blue on Linux (and in theory FreeBSD) using the pre-compiled binaries shipped with the source distribution. This behavior is enabled by not selecting any compiler USE flags, which was previously an error. I consider reducing the flags further to just "dmd", "gdc", "ldc2", as you proposed, for packages that don't deal with 3rd party Dlang libraries (i.e. Tilix➡️gtkd keep the verbose flags, dub could drop them). emerge @preserved-rebuild would then deal with binaries that dynamically link against a Phobos2 from a dmd version that has just been uninstalled.