Bugzilla Bug 46806

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 an attachment (id=28708) [edit]
dmd-0.8.1.ebuild (New Package)

I was just going to request somebody did this. Any word on the GCC frontend?

Created an attachment (id=31475) [edit]
Latest version of dmd

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 an attachment (id=44838) [edit]
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 an attachment (id=51903) [edit]
dev-lang/dmd/dmd-0.113.ebuild

Fixes the license:
> LICENSE="DMD"
> RESTRICT="nomirror"

Created an attachment (id=51904) [edit]
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 an attachment (id=52307) [edit]
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 an attachment (id=56499) [edit]
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 an attachment (id=83888) [edit]
Ebuild for DMD-0.151 on AMD64 supporting SLOTs

Created an attachment (id=99651) [edit]
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 an attachment (id=101192) [edit]
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