This is a new ebuild for the dmd compiler (stable branch). It will use dmd1.conf and is compatible with dmd-2 from sunrise. Not tested on x86 yet. http://paste.pocoo.org/show/523754/ http://www.digitalmars.com/ Reproducible: Always
Created attachment 296485 [details, diff] patch1
Created attachment 296487 [details, diff] dmd-1.066-makefile.patch
Created attachment 296489 [details, diff] slot-compat.patch
Created attachment 296491 [details] dmd-1.066.ebuild
Why is there no maintainer-wanted bug for this yet, while it's already in sunrise?
package now in sunrise https://overlays.gentoo.org/svn/proj/sunrise/sunrise/dev-lang/dmd/
> https://overlays.gentoo.org/svn/proj/sunrise/sunrise/dev-lang/dmd/ sry for beta-link correct link: https://overlays.gentoo.org/svn/proj/sunrise/reviewed/dev-lang/dmd/
This is a new ebuild and version patch for dmd-2.061. Both are adapted from former dmd-2.060.ebuild.
Created attachment 337742 [details] dmd-2.061.ebuild
Created attachment 337744 [details, diff] dmd-2.061-makefile.patch trivial changes to posix.mak as before in version 2.060
I grouped the directories under /usr/include together in one subdirectory dmd and made required changes to /etc/dmd.conf
dmd-1.* versions are deprecated and no longer supported since 31.12.2012
this bug report is for slot 1, please post ebuilds for slot 2 in one of those bug reports or create a new one also: deprecated compiler version does not mean we should drop it
Done.
*** Bug 455342 has been marked as a duplicate of this bug. ***
*** Bug 492518 has been marked as a duplicate of this bug. ***
*** Bug 376519 has been marked as a duplicate of this bug. ***
Created attachment 363982 [details, diff] app-emulation/emul-linux-x86-baselibs is not enough when enable multilib USE Flag and arch amd64.
(In reply to ncaq from comment #19) > Created attachment 363982 [details, diff] [details, diff] > app-emulation/emul-linux-x86-baselibs is not enough when enable multilib USE > Flag and arch amd64. I'm confused. Is it enough or not enough to depend on emul-linux-x86-baselibs?
(In reply to Marco Leise from comment #20) > (In reply to ncaq from comment #19) > > Created attachment 363982 [details, diff] [details, diff] [details, diff] > > app-emulation/emul-linux-x86-baselibs is not enough when enable multilib USE > > Flag and arch amd64. > > I'm confused. Is it enough or not enough to depend on > emul-linux-x86-baselibs? Yes.It is that. in amd64 system. libcurl.so is only 64bit. /usr/lib64/libcurl.so However,phobos2(32bit) and druntime(32bit) depends 32bit libcurl.so /usr/lib32/libcurl.so % qfile /usr/lib32/libcurl.so app-emulation/emul-linux-x86-baselibs (/usr/lib32/libcurl.so) So,dmd(enable multilib) depends app-emulation/emul-linux-x86-baselibs.
Ok, I'll fix it. On a related note there is currently a discussion about removing the curl wrapper from Phobos: http://forum.dlang.org/thread/mailman.25.1385365117.3242.digitalmars-d@puremagic.com And I created a Github repository for D on Gentoo, that includes GDC and LDC and allows parallel installation of several versions of DMD2 (and the other compilers). It currently is a proof of concept with only one library (GtkD) included, but maybe we can go this way: https://github.com/gentoo-dlang What it does is it generates a bunch of USE flags that match each compiler vendor and version combination (e.g. dmd-2.064). A library must be emerged with at least one of these USE flags and will have it compiled with that compiler and installed in a unique lib directory. -rpath on the default compiler command line will ensure, that executables linking against the shared version of the library will find it there. (https://github.com/gentoo-dlang/dlang/blob/master/README.md#q--a) Next year, I hope that the Github organization grows a bit and we have a little Dlang eco system on Gentoo. I'm not at all opposed to having this stuff in sunrise, but I saw no way how I could meet the quality standards with my USE flags hack ;) (Although in the end it is not much different from PYTHON_TARGETS)
I don't work on sunrise anymore, so if you want me to help, then you have to contact my personally.
(In reply to Julian Ospald (hasufell) from comment #23) > I don't work on sunrise anymore, so if you want me to help, then you have to > contact my personally. It is working ok, but it isn't perfect. For example an upgrade of a compiler causes all libraries to be reinstalled. This is already taking multiple hours for a single binding to Gtk (when supporting all 3 D-compilers in 32-bit and 64-bit). It would be better if only the part for the compiler that got upgraded had to be recompiled. But splitting each library into 3 similar packages for each compiler isn't feasible either. In any case this while it is working, it is still a "hack" with Portage and should really stay in its own overlay. The next step is to add the tools that are included in the sunrise dmd-ebuild in the gentoo-dlang-overlay and add it to layman, so this bug can be resolved WONTFIX. And then add the dmd-1 ebuild as well and remove D from sunrise to avoid confusion. Typically if anyone wants to contribute to gentoo-dlang I just make the co-owners of the repository, so if any of us should lose interest the repository can be revived by any of the other contributers.
(In reply to Marco Leise from comment #24) > The next step is to add the tools that are included in the sunrise > dmd-ebuild in the gentoo-dlang-overlay and add it to layman, so this bug can > be resolved WONTFIX. We do not close bugs as WONTFIX just because an ebuild is in some overlay.
So will it stay open for as long as dmd is actively developed?
(In reply to ncaq from comment #21) > Yes.It is that. > > in amd64 system. > libcurl.so is only 64bit. > /usr/lib64/libcurl.so > > However,phobos2(32bit) and druntime(32bit) depends 32bit libcurl.so > /usr/lib32/libcurl.so > > % qfile /usr/lib32/libcurl.so > app-emulation/emul-linux-x86-baselibs (/usr/lib32/libcurl.so) > > So,dmd(enable multilib) depends app-emulation/emul-linux-x86-baselibs. Should be fixed in Sunrise now.
There's a new approach to get this up to date in dlang overlay. I don't think anybody will work on this old ebuild again. We should close this bug!
(In reply to Berthold Humkamp from comment #28) > We should close this bug! No. This bug will be closed when/if the ebuild is in the portage tree. Overlays are irrelevant for the status of this bug.
I'll accept, we'll need an open case, for following the enhancements and to get releases into the main distribution. But it doesn't makes sense for anyone, to hold this old bug open, as those informations are overcome in total. The work in sunrise seems to be stopped and all active development is done in dlang overlay. It seems the guys there work very close with upstream and I can't see a good reason, to start a parallel approach to this. Those developers are the actual maintainers and we should get those into the boat, to beam releases into portage. By the way: I'm not part of this group myself. I just find this misleading information awful, as it will discourage interested people. We should open a new bug with informations up to date, if needed for history, with reflection to this old bug.
The reason I rebooted a D overlay was that my vision of it didn't fit in with how portage works and I would have been up for long debates about proposed changes before even having field tested them. D currently has one compiler front-end and 3 back-ends. ABI stability is not given between DMD and the other 2 and also not guaranteed from one release to the next. In fact I believe that currently there is not even a provision to make sure point releases are compatible in case you linked against the shared D stdlib. In addition there is the usual architecture friction with at least 2 library installations on multilib systems. For a developer - so my thinking - it is necessary to easily test with as many configurations as possible on their local system and only resort to CI systems, virtual machines, reboot to another OS or straight up use a second computer if they need to run code outside of Linux or on mobile devices. As far as installing all three compilers in all relevant versions with at least x86 and amd64 libraries in parallel goes, that is supported by portage. But when installing libraries I needed to know which compiler has stable shared library support, which compiler is stable at all, where to install libs for each compiler and version, how to pass DFLAGS and LDFLAGS flags to compilers that don't share a common syntax for either etc. The result was this eclass with accompanying list of compilers and what arch they are available and stable on: https://github.com/gentoo/dlang/tree/master/eclass Now when you install a D library or application from the overlay, it will provide the code in there with a range of D front-end versions it should compile with (these are very volatile still) and get a list of use-flags back. One for each compiler and version that fits and is at least as stable on the target arch as the ebuild in question. Ebuilds also tell the dlang.eclass whether they are applications or libraries via DLANG_PACKAGE_TYPE. Applications can only be built against one compiler, while libraries can be build against and installed for all available at once. Aside from that there is some code to convert compiler flags from env vars, handle quirks and provide compiler flags as well as a simple compilation receipt in absence of a flexible D build tool that can handle all of the above. In the mean time 'dub' (code.dlang.org) evolved as the main build tool for D. For the time being it doesn't seem to support specific install directories and likely resolves D library dependencies through its own cache, meaning a fixed system path and, I think, only static linking. This is mostly repeating myself from Comment 22, but I still don't see an isolated DMD ebuild returning to the main tree. It would be a step backwards.
@hasufell: With your point of view you are disguiding people or at least, if they are reading this long thread, you are wasting their time. If this is what you want, don't change anything!
(In reply to Berthold Humkamp from comment #32) > @hasufell: With your point of view you are disguiding people or at least, if > they are reading this long thread, you are wasting their time. If this is > what you want, don't change anything! You have just wasted our time with that comment. Please don't spam this bug report or I'll ask infra to clean this up. This bug report will stay open.
Sorry, I wanted to get you a bit angry, to get an answer. But I hoped you would be somewhat more objective: Since we gave our arguments, why this old obsolete bug and the ebuild it belongs to should be thrown away, you've given no real reason, why you want to hold it alive. What interest do you've got in not supporting the new way? Are you personally involved or what happened, that you behave this way? The old ebuild can't support all those facilities, Marco Leise pointed out already. - So what is going on here? My interest is, to make gentoo and it's environment as useful as possible. If you can tell me any good reason for your behaviour with this bug, I'll excuse me for my comment before.
I have to support hasufell: Since the sunrise version of dmd failed to re-build (likely new multilib handling with libcurl to blame), I went looking for the sunrise package description bug, and found this. Glad it was here to find updated info. So it should stay at least as long as there is a dmd package in sunrise. But even if that goes away, people might be tempted to report addition of a dmd package, unless there is an open bug report to that effect which they can find instead. So keep this open until dmd enters portage, along with any accompanying pakages, eclasses, infrastructure and whatever might seem reasonable by that time. Until then, this here is the place to find information like a pointer to the dlang repo.
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
Hello again, @Michal Gorny: Why just taking this old ebuilds into account? I can't see a reason, for going back about 2 years of development in this fast developing d-compiler scene. Marco Leise has a good working ebuild-system all around dmd, ldc and gdc in his own dlang-overlay. Maybe there are few edges, one can round up, but most of the newest upstream packages can be build his way, short after they are out. He's got his reasons, why he took the way with this way. Maybe, you can convince him, to change to sunrise, maybe you can't. But talking to and with him, discussing his ebuilds and the reasons why and where they are different to the old ebuilds, would help the whole scene. Maybe the easiest way thereafter is, to take over milestones of Marco's overlay into sunrise, maybe the solution is, to stay with this separate dlang-overlay just removing the old sunrise project or even to move the dlang-overlay mostly as it is to sunrise. - I don't know. - But ignoring the active delopment, just to keep alive an old fashioned project, is throwing away worthful work. I haven't got the time myself, to learn writing ebuilds as it is needed for such a big and actively growing project, but there are some people here already, who know both parts (dlang and writing ebuilds) good enough, to make the things running. The main problem seems to be, that those don't talk together for whatever reason. @Michal Gorny: Do you know someone, to mediate between both sides? I would like to do this, but I burned my mouth some time ago, as I tried to force some reaction. Therefore I don't think, I would be accepted from both sides ...
For people stumbling upon this, with similar objectives: I use x11-misc/obmenugen, which uses dmd:1 to build. dmd:1 in sunrise doesn't build on updated systems though, at the time of writing. While not really knowing what I'm doing, I created an ebuild for dmd-1.076 with major inspiration from the ebuild for dmd-1.066. I updated the patches (and removed one no longer needed), and now it builds on my system with profile 17. Surely it can be made nicer. It does compile, and x11-misc/obmenugen-0.5_p72 (from sunrise) is mergable with the result. The ebuild, and the patches, are found here: https://github.com/tsjk/gentoo-ebuilds/tree/master/dev-lang/dmd
(In reply to Tamas Jantvik from comment #38) I am surprised there are actually useful programs still out there that use D1. Granted, obmenugen was last updated over 9 years ago so there was no one there to make the move in recent years. If I was actively using obmenugen, I'd probably port it to D2 and add it to the dlang overlay. (D1 is kind of dead except for one company who kept back-porting bug fixes and obmenugen's source code looks small enough.) By the way: Mid last year, GDC was accepted into GCC pending review of the patches. If that makes it at last, we'll have a D2 compiler right in the portage tree, while the infrastructure remains in the dlang overlay. That's not the best situation, but it would work for the time being.
It happened, Dlang is in GCC-9. Upcoming issues: GDC requires a Dlang host compiler, which is currently only available from the dlang overlay. GDMD, the wrapper script to make GDC act like the reference compiler DMD, is not part of the base installation and can make some packages fail that expect a DMD-like compiler interface, which is why I install it as a forced dependency.
