On Monday, 11 November 2013 at 13:45:10 UTC, Iain Buclaw wrote:
> What do you define as being a "consistent deployment" ?

Similar path patterns for binaries, standard libraries and import modules. Similar compilation defaults. Use of FE version as primary one (GDC is especially useless here as its native version is tied to GCC version and says nothing about supported language).

On Sunday, 10 November 2013 at 18:14:25 UTC, Marco Leise wrote:
> 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.
>
See, this is one of those times where it might have been nice if D2 had gone with dmd2 for its binary name.  Regardless, if you want to support D1, make it a slot, and mask it for all arches-- we don't exactly want to encourage its use at this point, IMO.  This would be in the same general vein as dev-lang/dmd-bin (in the main tree, but terribly out-of-date).

Now, if it does get installed...an idea, though not a great one: If you look at mplayer and mplayer2, they both install roughly the same stuff to the same locations in their default distribution.  i.e. the binary is called mplayer in both the original and the fork.  So what happens in media-video/mplayer{,2} is mplayer2's stuff is renamed to match the $PN and there's an IUSE+=" symlink".  The symlink flag causes portage to install symlinks to the original mplayer stuff for transparent compatibility with various frontends and other stuff.

> 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.
>
My understanding was we were fixing the soname versioning for phobos, so this should theoretically be caught by @preserved-rebuild or revdep-rebuild.  Was I incorrect?

> 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.

I wonder at what point a d.eclass needs to be made to negotiate all of this; I'm really not sure.  On that note, you may want to watch out for degenerate cases like packages trying to select a preferred compiler, just in case.

-Wyatt

Am Mon, 11 Nov 2013 14:22:34 +0100
schrieb "Dicebot" <public@dicebot.lv>:

> `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

That looks very similar to an ebuild, with the major
difference that a PKGBUILD can define multiple packages and
an ebuild has USE flags I think.

> 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.

We will see how bad it becomes, hehe. I hope that it will mostly be the last to versions of a compiler and one older version for the one program you happen to use that wasn't updated for a while.

-- 
Marco

On Monday, 11 November 2013 at 15:02:24 UTC, Marco Leise wrote:
> That looks very similar to an ebuild, with the major
> difference that a PKGBUILD can define multiple packages and
> an ebuild has USE flags I think.

I think it was inspired by ebuilds originally but got some local tweaks over years. Multiple package support is relatively recent addition, for example.

Am Mon, 11 Nov 2013 15:43:11 +0100
schrieb "Wyatt" <wyatt.epp@gmail.com>:

> On Sunday, 10 November 2013 at 18:14:25 UTC, Marco Leise wrote:
> > 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.
> >
> See, this is one of those times where it might have been nice if D2 had gone with dmd2 for its binary name.  Regardless, if you want to support D1, make it a slot, and mask it for all arches-- we don't exactly want to encourage its use at this point, IMO. This would be in the same general vein as dev-lang/dmd-bin (in the main tree, but terribly out-of-date).

The versions in the sunrise overlay are already slotted for
D1/D2. The D1 dmd is renamed to dmd1 there. While I'm not
planning to rename dmd to dmd2, I took the concept a level
further and slotted for _every_ D version (except patch
levels). At least the current version of D1 cannot become
outdated any more. It's paradox I know. ;)

> Now, if it does get installed...an idea, though not a great one: If you look at mplayer and mplayer2, they both install roughly the same stuff to the same locations in their default distribution.  i.e. the binary is called mplayer in both the original and the fork.  So what happens in media-video/mplayer{,2} is mplayer2's stuff is renamed to match the $PN and there's an IUSE+=" symlink".  The symlink flag causes portage to install symlinks to the original mplayer stuff for transparent compatibility with various frontends and other stuff.

Positive on that one. I install dmd1.076 and dmd2.064 and have "eselect dlang set --dmd dmd1.076" set the dmd symlink to D1.

> > 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.
> >
> My understanding was we were fixing the soname versioning for phobos, so this should theoretically be caught by @preserved-rebuild or revdep-rebuild.  Was I incorrect?

Gentoo will keep the previous .so and the application
will continue to work, that is correct. But a clean state is
only reached when the application is rebuild for the new
version of the library using @preserved-rebuild and the
old .so is removed. And that's where Phobos might have a
changed API and the application wont compile any more.
It doesn't happen often I think, but there is also no
guarantee, no version number indicating a fixed API. And as
long as there are things like "shared" and allocators still to
iron out, I can live with that situation.

> > 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.
> 
> I wonder at what point a d.eclass needs to be made to negotiate all of this; I'm really not sure.

That was amongst the first things I had to write ^^. In a separate overlay it doesn't really matter how many of them you have. As long as it shortens ebuilds, I'm all for it. GCC really works that way, too. The ebuild is surprisingly short.

> On that note, you may want to watch out for degenerate cases like packages trying to select a preferred compiler, just in case.

That's the fun of ebuild writing. Apart from the compiler I
also need to pass compiler and version down to any
dependencies. And I saw no other way but doing that through
USE flags. If that system works out, it will be annoying as
hell. You might already have installed GtkD for gdc, dmd and
ldc in 3 different language versions = 9x and then comes a new
dependency that requests a 10-th version so you have to wait
through 10 compiles of GtkD again.
The only way to independently install a package multiple times
is through slots, and I want to keep that option for what it is
intended. Multiple API versions of the library in question.

> -Wyatt

-- 
Marco

Am Mon, 11 Nov 2013 15:08:22 +0100
schrieb "Dicebot" <public@dicebot.lv>:

> On Monday, 11 November 2013 at 13:45:10 UTC, Iain Buclaw wrote:
> > What do you define as being a "consistent deployment" ?
> 
> Similar path patterns for binaries, standard libraries and import modules. Similar compilation defaults. Use of FE version as primary one (GDC is especially useless here as its native version is tied to GCC version and says nothing about supported language).

That is a deficit. I'd like to make packages depend on a version of the language, but that's not easy with LDC and GDC at the moment. GDC is a mix of GCC version, D front-end version, an ancient version number 0.30 and a Git commit hash. :o)

Dicebot: I have decided that it makes most sense to not fight
GCC. D will eventually be an official GCC language and in the
Gentoo tree. That will be how you install GDC in the future.
We'll have to live with the binary, library and include
directories it creates.
I tried to have common directories between compilers, but
messing with the GCC installation is not on my agenda.
A good option might be to make the GDC ebuild behave exactly
like the GCC ebuild but block installation of GCC and GDC in
the same slot. That should be closest to what we will see in a
year (or so) when D is official in GCC. At that point the
separate GDC ebuild can be dropped.

As for detecting the language version there is always the option to compile this and see:

module version.d;
paragma(msg, __VERSION__);

-- 
Marco

Am Mon, 11 Nov 2013 14:48:37 +0100
schrieb "Wyatt" <wyatt.epp@gmail.com>:

> 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

Currently there is no environment to fix :). And that dmd.conf
file is now /etc/dlang/dmd2.064.conf.
It contains DFLAGS for 32-bit and 64-bit as well as version
specific include and library directories, making
--no-warn-search-mismatch obsolete in the general case.
The eselect only makes dmd, ldc, ldc2 and the man pages
available as symlinks for now. (Adapted from the Python
eselect module)

-- 
Marco

On Monday, 11 November 2013 at 15:54:11 UTC, Marco Leise wrote:
> D will eventually be an official GCC language and in the
> Gentoo tree. That will be how you install GDC in the future.
> We'll have to live with the binary, library and include
> directories it creates.

I actually fear that moment because the way GCC infrastructure works it is impossible to make language updates within single GCC stack version. So GDC users will likely just ignore obsolete version packaged with GCC and build their own. And we will get reports from frustrated newbies "I have installed gcc-d package from the repo and nothing compiles".

I like LLVM approach much better in that regard as it allows to define own versioning/release scheme.

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

> On Monday, 11 November 2013 at 15:54:11 UTC, Marco Leise wrote:
>
>> D will eventually be an official GCC language and in the Gentoo tree. That will be how you install GDC in the future. We'll have to live with the binary, library and include directories it creates.
>>
>
> I actually fear that moment because the way GCC infrastructure works it is impossible to make language updates within single GCC stack version. So GDC users will likely just ignore obsolete version packaged with GCC and build their own. And we will get reports from frustrated newbies "I have installed gcc-d package from the repo and nothing compiles".
>
> I like LLVM approach much better in that regard as it allows to define own versioning/release scheme.
>

Nobody makes that complaint about gccgo.  So what you are describing is an attitude unique to this community.


Regards
-- 
Iain Buclaw

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

On Monday, 11 November 2013 at 16:46:50 UTC, Iain Buclaw wrote:
> Nobody makes that complaint about gccgo.  So what you are describing is an
> attitude unique to this community.

How do they handle language updates in gccgo?