On Thursday, 27 September 2012 at 00:51:29 UTC, Brad Roberts
wrote:
> I have on my personal todo list a few major items (among many others):
>
> 1) add support for multiple projects (dmd2 being the only one currently)
> 2) add packaging of built artifacts for master builds
> 3) add uploading of packaged builds to github
> 4) on-demand builds of specific tags -- intended for release builds

At this point, wouldn't it be easier to use an existing solution
like Jenkins, and maybe add a few custom hooks where needed?

David

On Sep 27, 2012, at 12:20 AM, Brad Roberts <braddr@puremagic.com> wrote:

> On 9/27/2012 12:02 AM, Iain Buclaw wrote:
>> On 27 September 2012 03:14, Brad Roberts <braddr@puremagic.com> wrote:
>>> 
>>> #4 there implies it's a source package, though I could be mis-interpreting you.  Is there a path for externally built binary packages?  That's fairly counter to the general distribution philosophy for most of them, so I'm giong to guess no.
>>> 
>> 
>> For #4, yes.  Ubuntu is a better platform to approach for externally built binary-only packages.  But for debian, you could possibly do something similar to how eg: the flash-plugin installer package works - downloads the tar.gz/zip from an external site, extract and install / configure in system.
> 
> On reflection, #4 is not going to work for dmd.. neither ubuntu nor debian, nor most distributions are going to be happy with the license situation.  Nor are they happy with binary only packages anyway.  The right path is to do #4 but only for use on the dlang.org site (hosted via github's downloads api).  Then, add step #5 which is to automate source bundling and pushing to distributions.

I think you're probably right, but it's worth noting that the Ubuntu install asks whether to install a set of proprietary software at some point.  So the thought of a DMD package available to Ubuntu users somehow seems entirely reasonable.

On Thu, 2012-09-27 at 07:50 -0700, H. S. Teoh wrote:
[…]
> Yeah that's the other way to do it: build your own .deb's, and create an apt repository on dlang.org (or somewhere), then publish the repository URL. Then users can simply add the URL to /etc/apt/sources.list, and they will be able to use apt-get/aptitude to directly download and install it. You can even include a file in /etc/apt/sources.list.d in your .deb, so that once users install it the first time, the next package upgrade will automatically pull any new versions from dlang.org.
> 
> As an example, this is what Opera does.

Use of /etc/apt/sources.list.d turns out to be anathema to those of use who use approx.

Having a D apt repository remains a good move. In fact isn't there one already? It's contents could be widened to include all deb from D stuff.

(Except I haven't actually been able to make it work :-(

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wed, 2012-09-26 at 17:46 +0200, David Nadlinger wrote: […]
> Joseph, Russel, you seem to be both personally interested in D/LDC and quite knowledgeable about Debian-style packaging. Might I suggest that you think about joining the LDC forces as a package maintainer? It certainly isn't a huge amount of work to do, but many small items also add up…

It is certainly a considerable proposition. However I think getting an active Debian Maintainer to take the materials onto his/her list of responsibilities would, in my view, be a far more productive approach.

There are git-based tools for managing Debian packaging builds which fit well with D being a Git oriented community.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 28/09/12 00:31, Russel Winder wrote:
> Having a D apt repository remains a good move. In fact isn't there one
> already? It's contents could be widened to include all deb from D stuff.

There certainly used to be, but IIRC it has fallen into disuse.

But it's still better to have packages in the official repos, because that way people will be able to access them immediately without having to look for 3rd-party repos.

On 09/27/2012 12:02 PM, Joseph Rushton Wakeling wrote:
> I'd love to, but it would be irresponsible to commit to it as (right now
> especially) I don't have a very good idea of what time I'll be able to offer.

Just to follow up here -- a couple of days ago I pulled LDC from GitHub and built it.  First time I've tried LDC in a while as up until fairly recently I was not aware of the work on GitHub.

Very nice and friendly build process -- I like the inclusion of druntime and phobos as submodules.  The executables produced are nice and fast -- maybe about 10-15% slower than GDC for the number-crunching code I tested, but much faster than dmd-compiled programs, and the compilation process itself is super-fast.

I'll try and follow up in about 6 weeks' time by which time I should be settled in new job.  If it's all all right time-wise, and if someone can mentor me in production of good-quality deb files, I'd be willing to reconsider the maintainer issue. :-)

On Tuesday, 2 October 2012 at 13:46:58 UTC, Joseph Rushton Wakeling wrote:
> The executables produced are nice and fast -- maybe about 10-15% slower than GDC for the number-crunching code I tested, […]

Is any of the code public, in the sense that you could give e.g. me access for benchmarking purposes? We are currently using a presumably suboptimal optimization pass schedule, which for example doesn't include the auto vectorizer, but are going to switch to a new built-in pass manager soon (which uses the same pass schedule as Clang), and it would be very interesting to see its impact on performance-critical code.

David

On 10/02/2012 06:14 PM, David Nadlinger wrote:
> Is any of the code public, in the sense that you could give e.g. me access for
> benchmarking purposes? We are currently using a presumably suboptimal
> optimization pass schedule, which for example doesn't include the auto
> vectorizer, but are going to switch to a new built-in pass manager soon (which
> uses the same pass schedule as Clang), and it would be very interesting to see
> its impact on performance-critical code.

Here you go. :-)
https://github.com/WebDrake/Dregs

It's surely not the best D code ever written (it possibly inherits too much from C++ in design terms), but hopefully it's still useful for your purposes.