Hi! I've written an ebuild that installes the DigitalMars D compiler - dmd D is a new language designed by Walter Bright that is yet another successor of C The D comunity is growing so maybe you will like it. I would suggest dev-lang/dmd CU
Created attachment 28708 [details] dmd-0.8.1.ebuild (New Package)
I was just going to request somebody did this. Any word on the GCC frontend?
Created attachment 31475 [details] dmd-0.8.8
This ebuild works just fine. Please add to portage... Thanks...
It still needs some fixes, obviously. I have version 0.100 here, which would seem much more recent than 0.8.x. So the numbering scheme needs fixing first... I think that "0.8.8" should have been "0.88". But the real problem is this: the version you have just installed is probably not the same as the ebuild version. And related to this: you can't create a digest for their download. I doubt an ebuild without a working digest would be allowed into portage.
I've already emailed the authors about the versioning... Let's see what happens...
Well, looks the authors started adding version numbers to zip files: http://www.digitalmars.com/d/changelog.html At least the latest version of DMD at the moment has version number in it: ftp://ftp.digitalmars.com/dmd.105.zip
Can you please add this to portage?
Version 0.106 is out... Anyone watching this?
Created attachment 44838 [details] dev-lang/dmd-0.106.ebuild New ebuild compatible with DMD version 0.106
The new ebuild should be ready for inclusion in the Portage tree. Newer versions should only take a version bump. The ebuild works with (at least) the newest version of Portage.
Created attachment 51903 [details] dev-lang/dmd/dmd-0.113.ebuild Fixes the license: > LICENSE="DMD" > RESTRICT="nomirror"
Created attachment 51904 [details] DMD This is the license.txt for DMD (for /usr/portage/licenses/DMD)
Since this (DMD) is a binary-only package, does this mean it should be under /opt ?
Created attachment 52307 [details] dev-lang/dmd/dmd-0.114.ebuild New release version, added manpages
I'm ignoring Comment 14 for now and just leaving it in /usr...
About Comment #14. It should go into /opt if there is no "hardwired" problem. It has been some time since I last tried it. Maybe I'll look at it again
The only "hardwiring" is /usr/lib/phobos, which can be changed in the ebuild if needed. (leaving in the default location is easier...) And of course there needs to be entries in PATH and DFLAGS/dmd.conf if not using the default /usr/bin and /usr/lib directories - I believe this would go in /etc/env.d/dmd ? See http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler
Works nice with me. gald I found this ebuild. I belive this belongs to /opt, if possible. Appart from that, I think this should go into portage soon, under ~x86. As far as I am conserned, it can go into portage as is, and move to /opt in future release (like a 0.114-r1)
DMD should definitely not go into the /opt directory for several reasons: 1. It would be disturbing to set your PATH (and MANPATH) environment variables if you want to be able to use the DMD compiler (or man pages) from the command-line (at least until we have a dmd-config script which is definitely not necessary at the moment) 2. DMD fits rather nicely into the filesystem tree. All the files are where the user would expect them to be in case of a package installation. It currently creates 8 files and 2 directories (assuming a normal setup), which doesn't really interfere with anything else: /etc/dmd.conf /usr/bin/dmd /usr/bin/dumpobj /usr/bin/obj2asm /usr/lib/libphobos.a /usr/share/man/man1/dmd.1.gz /usr/share/man/man1/dumpobj.1.gz /usr/share/man/man1/obj2asm.1.gz --- /usr/lib/phobos /usr/share/doc/dmd-0.114
> 1. It would be disturbing to set your PATH (and MANPATH) environment > variables if you want to be able to use the DMD compiler (or man pages) from > the command-line (at least until we have a dmd-config script which is > definitely not necessary at the moment) Java is in /opt, and I don't need to set my PATH before using the Java compiler. I don't think you'd need dmd-config either, just an entry in /etc/env.d.
Trejkaz Xaoza wrote: > Java is in /opt, and I don't need to set my PATH before using the Java > compiler. I don't think you'd need dmd-config either, just an entry i > /etc/env.d. Sorry, you're right about that, I didn't think about env.d. I still prefer the current layout though.
dmd 0.115 is out. Just copy dmd-0.114.ebuild to dmd-0.115.ebuild should do the trick.
dmd 0.116 is out. as before, copy and rename the previous ebuild, and everything is going to be fine. This makes me think that this ebuild is pretty stable, and working well. why doesn't it go into portage?
(cd dmd/src/phobos; find -name '*.d' | grep -v internal | xargs tar c) | \ (cd "${D}/usr/lib/phobos"; tar xo) Do we really need this kind of ugliness in the ebuild just to filter out the internal/ directory and .c/.cpp/.h files? It doesn't save us a lot of space and 'grep -v internal' might potentially conflict with future module names. 'grep -v ^internal/' would solve this problem, but I would prefer something more obvious instead of the code above.
About Comment 25: Such ugliness would *not* be needed if upstream just provided a "make install"...
Created attachment 56499 [details] dev-lang/dmd/dmd-0.121.ebuild Updated to version 0.121, added the "internal" files back in. Source files, Makefiles, and unittest are still NOT included. (thus, regarding Comment 25, the workaround is still needed) I'm ignoring Comment 14, and leaving the DMD install in /usr... It matches the manual installation, and the RPM package too. Since this package is a binary, it is for Pentium only (X86). Phobos (and DMD) does not yet support the X86_64 arch, either. Don't forget to add the DMD license to /usr/portage/licenses (See the attachment to Comment 13, for the DMD license text) digest-dmd-0.121: MD5 281c3a9679641e46710496e3f2acbb8a dmd.121.zip 3202057
As far as I am conserned, all versions of dmd since this ebuild has be introduced (0.121) up to the current 0.143 have been working fine just by renaming this ebuild to match the verion. isn't it time this went into portage? Just for the sake of the compiler, it would be nice to have it, but there are also other programs (admitedly not many, but still some) depending on it too, so inclusion would be most welcome.
Just adding myself to CC :) I'd really love to see this in portage, like some others.. but it seems there's been no progress on it for quite some time?
(In reply to comment #29) > I'd really love to see this in portage, like some others.. but it seems there's > been no progress on it for quite some time? Yeah, it looks like you have to offer sexual favors to the package maintainers to get this into Portage.
(In reply to comment #30) > Yeah, it looks like you have to offer sexual favors to the package > maintainers to get this into Portage. That would be funny, because you essentially have to offer to*be* the package maintainer, to get this into portage ;). Please see my comments on #48136 (the rival D compiler) for a more details on the general situation and what would be needed to do to add D cleanly. Also, if there are any D-related bugs I missed, please add them as dependencies to #118209. Please do *not* start flames or misc discussion on that bug, as it is simply a tracker. However I would wellcome somebody stepping forward, willing to take up on a role of D-language maintainer. Usual recruitment rules apply - please provide some information about yourself, links to the relevant bugs, anything you would want to show.. George
Created attachment 83888 [details] Ebuild for DMD-0.151 on AMD64 supporting SLOTs
Created attachment 99651 [details] Ebuild for DMD-0.169 on AMD64 and X86 using SLOTs
(In reply to comment #33) I had to add "sys-libs/libstdc++-v3" to RDEPEND in order to get this compiler to run on my system (x86 2006.1).
Created attachment 101192 [details] Ebuild for DMD-0.173 on AMD64 and X86 using SLOTs fixed the libstdc++-v3 on x86 systems
*** Bug 159662 has been marked as a duplicate of this bug. ***
Thanks to everyone for their inputs, DMD v1.0.0 is now in portage. Track amd64 keyword request on bug #170131
