On 10 November 2013 10:33, Jacob Carlborg <doob@me.com> wrote:

> On 2013-11-09 14:52, Marco Leise wrote:
>
>  "dmd" and it's ilk (gdmd, ldmd2) have a known command line
>> syntax, "dc" doesn't. Symlinks are most useful when the semantic stays the same.
>>
>
> I might have been a bit unclear. I was thinking we had a symlink called "dc" that would point to dmd, gdmd or ldmd2. I don't like that you can invoke "dmd" and it will compile using GDC.
>
>
It also makes no sense as both have wildly different compiler switch names.  And for the switches that are the same, both interpret the switches differently. ie:  '-I ./imports'  works for GDC but not DMD (for some reason DMD doesn't like spaces between switches and switch arguments).


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 2013-11-10 12:14, Iain Buclaw wrote:

> It also makes no sense as both have wildly different compiler switch
> names.  And for the switches that are the same, both interpret the
> switches differently. ie:  '-I ./imports'  works for GDC but not DMD
> (for some reason DMD doesn't like spaces between switches and switch
> arguments).

Right, it also depends on the flag. They're all quite inconsistent.

-- 
/Jacob Carlborg

Am Sun, 10 Nov 2013 14:20:05 +0100
schrieb Jacob Carlborg <doob@me.com>:

> On 2013-11-10 12:14, Iain Buclaw wrote:
> 
> > It also makes no sense as both have wildly different compiler switch names.  And for the switches that are the same, both interpret the switches differently. ie:  '-I ./imports'  works for GDC but not DMD (for some reason DMD doesn't like spaces between switches and switch arguments).
> 
> Right, it also depends on the flag. They're all quite inconsistent.

Well, it doesn't hurt to add a "dc" symlink the way you described it. As long as you use no spaces after -I and resort to the basic stuff like adding -release -O -inline etc. it should work.

I'm currently testing the parallel installation of dmd-versions in Gentoo. After finding starting and stopping work on a few experiments to figure out what is possible with ebuilds, it was time for something simpler.

The biggest problem was the library path. I chose
/usr/lib{32,64}/dlang/<compiler>/ for now, where <compiler>
is "dmd-2.064". I don't know if I should add the .2 minor
version, too. But that's really a minor detail.
I solved that by replacing all occurrences of /etc/
with /etc/dlang/dmd-<version>/ in inifile.c and then putting
dmd.conf there with two sections for [Environment32] and
[Environment64], that point to the afore mentioned library
paths for 32-bit and 64-bit respectively.
I didn't know of these two sections until I looked at the dmd
source code. They also mean that I can remove
--no-warn-search-mismatch from DFLAGS, since 32-bit and
64-bit libraries are now clearly separated.

Next, I'll probably modify the dmd-2.063.2 ebuild in the same fashion and look at the eselect python module to create a counterpart for dlang.

-- 
Marco

On Saturday, 9 November 2013 at 13:23:33 UTC, Marco Leise wrote:
> Yeah, I was pointing at the lock-step upgrade nature of D
> development. You can't really update one without the other
> when it comes to every day package management.

True. This why I have them all in a single PKGBUILD (ebuild analog I guess) despite those looking separate in package manager.

>> > - Tools tend to expect that "dmd" is available as a command.
>> 
>> Actually I don't think this is true for newer ones. There are plenty that tend to either use `rdmd` or detect compiler present in the system.
>
> Good, the only thing that might go wrong then is alternate
> binary names or install locations.

Well the idea is simple - whatever install locations are, packager provides default /etc/dmd.conf (ldc has similar conf file and gdc needs to be patched during build) that allow plain compiler invocations to "just work" without figuring out any actual path. I also have common base path for all D modules installed via `pacman` - "/usr/include/dlang/" which is in default `-I` list so that any library installed that way can be directly imported with no extra steps.

> Your experience is welcome! Does D1 have a place in that
> model?

AFAIK no one uses D1 but company I am working for :P

> And what does really happen when you work with e.g.
> dmd-2.065 and found a D application in the tree that hasn't
> been updated for a few weeks, so it still requires 2.064?

It is somewhat easier in Arch case as core repositories provide pre-compiled binary packages. So it does not really matter what compiler version is required for application if it is statically linked and is not a library on its own. For source-based packaged (AUR in Arch case) I'd send a pull request upstream :) Or mark it out-of-date and wait :)

> It would more or less mean that the whole D package system
> would have to be updated in one go, when all packages are
> updated to the latest D version, which can take a while.

It is pretty much what happens right now anyway as it is defined by nature of D versioning / releases and there is not much we can do about it :)

>> > Next a symlink should be established to the current
>> > implementation of dmd, e.g.: /bin/dmd -> /bin/ldmd2.
>> > This symlink could be managed with an eselect plugin as it is
>> > already done for other languages like Python or the Java
>> > Runtime.
>> 
>> And what if one wants to have all 3 simultaneously?
>
> You call them by their real names. :)

Well, "dmd" IS real name for dmd ;) In that sense that "dc" proposal makes much more sense.

Am Sun, 10 Nov 2013 17:34:49 +0100
schrieb "Dicebot" <public@dicebot.lv>:

> On Saturday, 9 November 2013 at 13:23:33 UTC, Marco Leise wrote:
> > Yeah, I was pointing at the lock-step upgrade nature of D development. You can't really update one without the other when it comes to every day package management.
> 
> True. This why I have them all in a single PKGBUILD (ebuild analog I guess) despite those looking separate in package manager.

So a single PKGBUILD can advertise multiple items to install? And when you later install more from the same package you just run the PKGBUILD again and it reinstalls everything plus the new options?

> >> > - Tools tend to expect that "dmd" is available as a command.
> >> 
> >> Actually I don't think this is true for newer ones. There are plenty that tend to either use `rdmd` or detect compiler present in the system.
> >
> > Good, the only thing that might go wrong then is alternate binary names or install locations.
> 
> Well the idea is simple - whatever install locations are, packager provides default /etc/dmd.conf (ldc has similar conf file and gdc needs to be patched during build) that allow plain compiler invocations to "just work" without figuring out any actual path. I also have common base path for all D modules installed via `pacman` - "/usr/include/dlang/" which is in default `-I` list so that any library installed that way can be directly imported with no extra steps.

+1 I use this prefix now, too. Each compiler also has a subdirectory there.

> > Your experience is welcome! Does D1 have a place in that model?
> 
> AFAIK no one uses D1 but company I am working for :P

Yeah, and they hopefully don't use Gentoo... maybe it is time to drop that version if it causes trouble. I'll try to have at least an dmd-1.076 ebuild though. It is also a good test for the whole multiple versions at once idea.

> > And what does really happen when you work with e.g. dmd-2.065 and found a D application in the tree that hasn't been updated for a few weeks, so it still requires 2.064?
> 
> It is somewhat easier in Arch case as core repositories provide pre-compiled binary packages. So it does not really matter what compiler version is required for application if it is statically linked and is not a library on its own. For source-based packaged (AUR in Arch case) I'd send a pull request upstream :) Or mark it out-of-date and wait :)

Too many smilies, hehe. Well, it should be possible to have at least one installable version of every package at any time. Unless that package hasn't been updated for 10 months or so. I don't want to run into a situation where you can't update dmd because some application isn't updated or where I do update dmd early and D programs can't be installed any longer until they work with that latest version of D.

> > It would more or less mean that the whole D package system would have to be updated in one go, when all packages are updated to the latest D version, which can take a while.
> 
> It is pretty much what happens right now anyway as it is defined by nature of D versioning / releases and there is not much we can do about it :)

Well, we can keep "old copies" around till no one needs them anymore. This is done for several other languages on Gentoo and I have it working more or less for dmd now.

> >> > Next a symlink should be established to the current
> >> > implementation of dmd, e.g.: /bin/dmd -> /bin/ldmd2.
> >> > This symlink could be managed with an eselect plugin as it is
> >> > already done for other languages like Python or the Java
> >> > Runtime.
> >> 
> >> And what if one wants to have all 3 simultaneously?
> >
> > You call them by their real names. :)
> 
> Well, "dmd" IS real name for dmd ;) In that sense that "dc" proposal makes much more sense.

Yep. I thought of it as an opt-in symlink in case dmd isn't installed, so it could be emulated with gdmd or ldmd2. /bin/dmd -> /usr/bin/dmd might also be an option for that... Nah, I'll see what might be required by some tools.

-- 
Marco

Does anyone have an idea how to go about GDC, especially once the D front-end is integrated? Since GCC installations are configured with gcc-config, there is a conflict for "eselect dlang". To clarify, gcc-config copies the executables from

/usr/x86_64-pc-linux-gnu/gcc-bin/<version>/*
to
/usr/bin/*

I guess I should just stick to DMD and LDC for it then?
By the way "dc" is already the name of an arbitrary precision
expression evaluator and cannot be used for a symlink to the D
compiler of choice. :p

-- 
Marco

On Monday, 11 November 2013 at 05:21:22 UTC, Marco Leise wrote:
> Does anyone have an idea how to go about GDC, especially once
> the D front-end is integrated? Since GCC installations are
> configured with gcc-config, there is a conflict for "eselect
> dlang". To clarify, gcc-config copies the executables from
>
> /usr/x86_64-pc-linux-gnu/gcc-bin/<version>/*
> to
> /usr/bin/*
>
> I guess I should just stick to DMD and LDC for it then?
> By the way "dc" is already the name of an arbitrary precision
> expression evaluator and cannot be used for a symlink to the D
> compiler of choice. :p

I ignore gcc-config for GDC and explicitly maintain list of files to install and their target locations (it is very short). Not very gcc-ish but more allows more consistent deployment between different D compilers.

On Sunday, 10 November 2013 at 18:14:25 UTC, Marco Leise wrote:
>> True. This why I have them all in a single PKGBUILD (ebuild analog I guess) despite those looking separate in package manager.
>
> So a single PKGBUILD can advertise multiple items to install?
> And when you later install more from the same package you just
> run the PKGBUILD again and it reinstalls everything plus the
> new options?

`PKGBUILD` in Arch Linux is simply a standard package building script, essentially a bash script with metadata. It is not a package on its own, in is used to create ones. It is convenient for maintenance to generate packages with a shared/related built process from a single PKGBUILD. This, for example, is the one for dmd stack : https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/dmd/PKGBUILD

>> AFAIK no one uses D1 but company I am working for :P
>
> Yeah, and they hopefully don't use Gentoo... maybe it is time
> to drop that version if it causes trouble. I'll try to have
> at least an dmd-1.076 ebuild though. It is also a good test
> for the whole multiple versions at once idea.

Well, wish you good best luck with it :) I don't have any plans to support it in main repositories (actually, other TU's would have yelled at me even if I did as it is against Arch design :P)

> Too many smilies, hehe. Well, it should be possible to have at
> least one installable version of every package at any time.
> Unless that package hasn't been updated for 10 months or so.
> I don't want to run into a situation where you can't update
> dmd because some application isn't updated or where I do
> update dmd early and D programs can't be installed any longer
> until they work with that latest version of D.

If such package is a stand-alone application and does not seem to be maintained for some time it can be adjusted to use DVM to retrieve older version specifically to build itself. Not very convenient, but won't at least pollute the system with dozens of different compiler/phobos versions.

On 11 November 2013 13:14, Dicebot <public@dicebot.lv> wrote:

> On Monday, 11 November 2013 at 05:21:22 UTC, Marco Leise wrote:
>
>> Does anyone have an idea how to go about GDC, especially once the D front-end is integrated? Since GCC installations are configured with gcc-config, there is a conflict for "eselect dlang". To clarify, gcc-config copies the executables from
>>
>> /usr/x86_64-pc-linux-gnu/gcc-bin/<version>/*
>> to
>> /usr/bin/*
>>
>> I guess I should just stick to DMD and LDC for it then?
>> By the way "dc" is already the name of an arbitrary precision
>> expression evaluator and cannot be used for a symlink to the D
>> compiler of choice. :p
>>
>
> I ignore gcc-config for GDC and explicitly maintain list of files to install and their target locations (it is very short). Not very gcc-ish but more allows more consistent deployment between different D compilers.
>


What do you define as being a "consistent deployment" ?


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, 11 November 2013 at 05:21:22 UTC, Marco Leise wrote:
> Does anyone have an idea how to go about GDC, especially once
> the D front-end is integrated? Since GCC installations are
> configured with gcc-config, there is a conflict for "eselect
> dlang". To clarify, gcc-config copies the executables from
>
> /usr/x86_64-pc-linux-gnu/gcc-bin/<version>/*
> to
> /usr/bin/*
>
> I guess I should just stick to DMD and LDC for it then?
> By the way "dc" is already the name of an arbitrary precision
> expression evaluator and cannot be used for a symlink to the D
> compiler of choice. :p

On this point, it may be time to get on Freenode and hit up #gentoo-dev-help and see what they say.  Off the top of my head, EAPI 2 introduced USE deps, so you may be able to get away with specifying sys-devel/gcc[d] as fulfilling your virtual.

As far as eselect goes, I would use that only for fixing up the environment and the paths in sc.ini (and the primary compiler symlink, if you choose to go that route). I'm not familiar with the guts of it, but from what I've been told, an eselect module for gcc has been tried several times, but has always met unfortunate circumstances.

-Wyatt