On Thursday, 13 February 2014 at 12:20:09 UTC, Sönke Ludwig wrote:
> Looks like this is more common than it seemed. I can try to compile on the older Ubuntu 11.10 VM, or, if someone can donate an RPM recipe and the necessary commands, I could also set up a Fedora VM and provide a proper RPM package.

Ask and ye shall receive

https://github.com/GlobecSys/w3Vibe/blob/master/dmd.spec
https://github.com/GlobecSys/w3Vibe/blob/master/dub.spec

You should run this before:

$ yum install rpm-build binutils libstdc++-devel wget gcc gcc-c++ make openssl libcurl-devel tar kernel-devel

then you can run

$ rpm-build -ba dmd.spec
$ rpm -ivh ~/rpmbuild/RPMS/x86_64/dmd*.rpm
$ rpm-build -ba dub.spec

Your RPMs will be in ~/rpmbuilds/RPMS/x86_64

I didn't get into making a i686 version of the spec.. I assume it's just a matter of changing %define _archmodel 64 to %define _archmodel 32 in dmd.spec, but for dub I'm not too sure how it handles it.

On Thursday, 13 February 2014 at 19:13:30 UTC, Etienne wrote:
> $ rpm-build -ba dmd.spec

Sorry, that was
$ rpmbuild -ba dmd.spec

rpm-build is the package name, rpmbuild is the binary filename.

Am 13.02.2014 20:15, schrieb Etienne:
> On Thursday, 13 February 2014 at 19:13:30 UTC, Etienne wrote:
>> $ rpm-build -ba dmd.spec
>
> Sorry, that was
> $ rpmbuild -ba dmd.spec
>
> rpm-build is the package name, rpmbuild is the binary filename.

Thank you! Would it also be possible to make a binary-only package from a pre-built binary without the dmd dependency?

The way it is now, it would be nice to have in a full repository like the one Jordi Sayol maintains for Debian, but it's less practical for direct distribution.

Am 13.02.2014 13:20, schrieb Sönke Ludwig:
> Am 13.02.2014 12:40, schrieb Russel Winder:
>> … I have a single filestore and thus a single ~/.dub but the compilation
>> products of dub are not in architecture dependent locations so I cannot
>> work with OSX and Linux at the same time.
>
> I'll add the OS to the generated folder names, I didn't think of this
> case when defining the format of those and wanted to keep them as short
> as possible.
>

Done in RC 4

Uploaded RC 4 with fixes for the issues encountered so far. If no other critical error or regression occurs, this one will go final.

Am 13.02.2014 02:01, schrieb Jakob Ovrum:
> On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig wrote:
>> DUB 0.9.21 is currently in the RC stage. Before tagging a release, I'd
>> like it to get a little more exposure. Apart from checking if building
>> works (dependencies are now built separately by default), there are
>> two new features that could also benefit from more testing:
>>
>>  - "dub test" will now automatically execute the unit tests of a
>>    package (see "dub test --help" for more information)
>>
>>  - Sub packages can now be in sub folders (the recommended approach):
>>
>>    "name": "somepack",
>>    "subPackages": {
>>        "subpack1/",
>>        "plugins/someplug/"
>>    }
>>
>>    Those sub packages can be publicly referenced as a dependency for
>>    example as "somepack:subpack1" (assuming that the the package in
>>    "subpack1")
>>
>> The binaries can be found on http://code.dlang.org/download ("Latest
>> preview").
>>
>> Pre-release thread on the DUB forum:
>> http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/965/
>
> Added package description files for all the LuaD examples, and they all
> work using the new build model with the exception of the `hello` example
> (which you are aware of).
>
> The dynamic library example also builds correctly, but it would be nice
> to have a way to specify how to run it, so I filed that over at the dub
> issue tracker.
>
> I also reworked LuaD's readme files to emphasize dub :)

Nice! The dylib run addition will be scheduled for the next release (hopefully ready in about 3 weeks).

Am 13.02.2014 13:58, schrieb "Casper Færgemand" <shorttail@hotmail.com>":
> On Thursday, 13 February 2014 at 12:57:02 UTC, Sönke Ludwig wrote:
>> After some testing, all I can get is multiple -m64 switches, which
>> isn't pretty, but shouldn't do any harm. Do you compile with
>> --arch=x86_64 or did you manually add the -m64 flag somewhere? The
>> latter would explain the issue, as only -version= flags are inherited
>> downwards to the dependencies (except for build type flags).
>
> Herp derp, didn't know about that one. It works now.
> Is it possible to specify in package.json?

Currently it can be controlled only by command line switches. But how about the possibility of configuring a default architecture in the user or system wide dub configuration file?

And possibly also per package in a configuration file in "package-path/.dub/"... but it seems to me that this should stay independent of the package description, since the platform is more or less determined by the target machine and not the package itself, or do you have a specific use case in mind?

On Thursday, 13 February 2014 at 20:17:39 UTC, Sönke Ludwig wrote:
> The way it is now, it would be nice to have in a full repository like the one Jordi Sayol maintains for Debian, but it's less practical for direct distribution.

I provided the dmd.spec because I took the opportunity to make one as well, but it's not a dependency here. It may be easier to install the most recent dmd master using it, because the RPMs for DMD are currently generated through these shell scripts:
https://github.com/D-Programming-Language/installer/tree/master/linux

And I thought you may want to supply it with dub in case people are newcomers and want the most recent version.

But the dub x64 RPM that is generated from this dub.spec file will be a binary file that depends only on libcurl, it carries a dub binary with some requirements and installation paths (/usr/bin).

In any case, every time you issue a new dub release, you'll still need to generate a x64 DEB, x86 DEB, x64 RPM and x86 RPM file as well to distribute it on every linux platform. You should use debian 6 and fedora 18, always a couple versions behind, to make sure its not built against too recent libraries.

Do you want me to provide something more convenient, or can you do with dub.spec files & rpmbuild?

On Friday, 14 February 2014 at 00:25:43 UTC, Etienne wrote:
> On Thursday, 13 February 2014 at 20:17:39 UTC, Sönke Ludwig wrote:
> Do you want me to provide something more convenient, or can you do with dub.spec files & rpmbuild?

Well of course it would be best for any multi-platform program to have grouped generators in this way:

https://github.com/D-Programming-Language/installer/

The spec file only covers RPMs from fedora/centos/rhel, but there's tons of other platforms.

> On Friday, 14 February 2014 at 00:25:43 UTC, Etienne wrote:
> The spec file only covers RPMs from fedora/centos/rhel, but there's tons of other platforms.

I put some thought into it some more and you were probably talking about a linux generic 32bit binary that never needs to be updated, and sends platform info to a vibe.d server, which sends back most recent RPM/DEB/etc or if it's not built yet and the server can also automatically build the RPM from the github master if it's not the most recent and send it to be installed.