www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Preflight of DUB 0.9.21 (RC 3)

reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig+dforum outerproduct.org> writes:
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/
Feb 12 2014
next sibling parent reply "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig 
wrote:

 dependencies are now built separately by default


You mean DUB won't recompile dependencies from scratch but will 
do it incrementally? I'm not really sure how it does it right now 
either.
Feb 12 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 11:11, schrieb Andrej Mitrovic:

 On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig wrote:

 dependencies are now built separately by default


 You mean DUB won't recompile dependencies from scratch but will do it
 incrementally? I'm not really sure how it does it right now either.


In 0.9.20, it used to gather all source files of all packages in the 
dependency tree and built them at once (when necessary). Now, by 
default, it will build each dependency as a separate static library and 
also builds only those dependencies that have changed or those that 
depend on other dependencies that have changed.

The --combined switch can be used to get (almost) the old behavior. 
Almost, because DUB now also respects the exact "targetType" of a 
package and will always build a static library if "staticLibrary" is 
given and aways includes the source files on the parent package build 
command when "sourceLibrary" is used. Previously, all dependencies were 
basically treated as "sourceLibrary".
Feb 12 2014
parent "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Wednesday, 12 February 2014 at 10:58:28 UTC, Sönke Ludwig 
wrote:

 In 0.9.20, it used to gather all source files of all packages 
 in the dependency tree and built them at once (when necessary). 
 Now, by default, it will build each dependency as a separate 
 static library.


Nice. Hope it works fine (especially w.r.t. that -allinst mess 
we've had since recently).
Feb 12 2014
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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)


How do I handle `example` subdirectories with the new build 
process? I looked at vibe.d's examples (the simple HTTP server 
stuff to be specific) but they don't seem to handle linking (do 
they really build without --combined?). Is there a way to add 
linker search directories so my examples can link to the 
library's static library builds? Or is this supposed to be 
handled automatically for library dependencies?


  - "dub test" will now automatically execute the unit tests of a
    package (see "dub test --help" for more information)


I can confirm this works for the LuaD package, which is a pretty 
typical D library in terms of structure.
Feb 12 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 14:14, 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)


 How do I handle `example` subdirectories with the new build process? I
 looked at vibe.d's examples (the simple HTTP server stuff to be
 specific) but they don't seem to handle linking (do they really build
 without --combined?). Is there a way to add linker search directories so
 my examples can link to the library's static library builds? Or is this
 supposed to be handled automatically for library dependencies?


The latter. The target binaries of dependencies (recursively) are 
automatically linked against the final application.

Specifying linker search paths is not possible right now (at least some 
time ago this was problematic for DMD on Windows, not sure what the 
current state is). But specific library files can be added as 
`"sourceFiles"`. Those will be passed to the compiler at the linking 
stage, which passes them on to the linker.


  - "dub test" will now automatically execute the unit tests of a
    package (see "dub test --help" for more information)


 I can confirm this works for the LuaD package, which is a pretty typical
 D library in terms of structure.


Thanks for testing!
Feb 12 2014
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 12 February 2014 at 18:06:19 UTC, Sönke Ludwig 
wrote:

 The latter. The target binaries of dependencies (recursively) 
 are automatically linked against the final application.


Hm, I'm getting a failure to link, with just one symbol reported 
missing. Further, -allinst makes no difference. I checked the 
verbose output and the parent library was indeed being passed 
automatically when linking the example executable, so for now I 
assume it's a DMD/OPTLINK bug. I'll report back with more 
information if I can't reproduce it without Dub.

Really cool that libraries are automatically linked, I'm really 
liking how Dub is shaping up!


 Specifying linker search paths is not possible right now (at 
 least some time ago this was problematic for DMD on Windows, 
 not sure what the current state is). But specific library files 
 can be added as `"sourceFiles"`. Those will be passed to the 
 compiler at the linking stage, which passes them on to the 
 linker.


Yeah, I remember OPTLINK being difficult in this regard. IIRC 
though, there is an environment variable one can set.

[1] https://github.com/JakobOvrum/LuaD/tree/master/example/hello
Feb 12 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 19:56, schrieb Jakob Ovrum:

 On Wednesday, 12 February 2014 at 18:06:19 UTC, Sönke Ludwig wrote:

 The latter. The target binaries of dependencies (recursively) are
 automatically linked against the final application.


 Hm, I'm getting a failure to link, with just one symbol reported
 missing. Further, -allinst makes no difference. I checked the verbose
 output and the parent library was indeed being passed automatically when
 linking the example executable, so for now I assume it's a DMD/OPTLINK
 bug. I'll report back with more information if I can't reproduce it
 without Dub.


I've reduced it and filed a bug:

https://d.puremagic.com/issues/show_bug.cgi?id=12144

It was actually great that this occurred in LuaD, because I suspect that 
I'm possibly hit by the same bug, but my code base is so large that it 
takes over a week to run dustmite on it.
Feb 12 2014
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 12 February 2014 at 20:24:28 UTC, Sönke Ludwig 
wrote:

 I've reduced it and filed a bug:

 https://d.puremagic.com/issues/show_bug.cgi?id=12144

 It was actually great that this occurred in LuaD, because I 
 suspect that I'm possibly hit by the same bug, but my code base 
 is so large that it takes over a week to run dustmite on it.


Wow, well done. Sorry for not including all the relevant 
information right away, might have saved you some time. I was 
actually putting all the information together for the post, but 
as I saw using --verbose that everything *looked* right, I 
decided to wait and see if it really was a problem with Dub first 
- you were one step ahead of me there.

Thanks!
Feb 12 2014
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 12 February 2014 at 20:34:35 UTC, Jakob Ovrum wrote:

 On Wednesday, 12 February 2014 at 20:24:28 UTC, Sönke Ludwig 
 wrote:

 I've reduced it and filed a bug:

 https://d.puremagic.com/issues/show_bug.cgi?id=12144

 It was actually great that this occurred in LuaD, because I 
 suspect that I'm possibly hit by the same bug, but my code 
 base is so large that it takes over a week to run dustmite on 
 it.


 Wow, well done. Sorry for not including all the relevant 
 information right away, might have saved you some time. I was 
 actually putting all the information together for the post, but 
 as I saw using --verbose that everything *looked* right, I 
 decided to wait and see if it really was a problem with Dub 
 first - you were one step ahead of me there.

 Thanks!


... which the unreferenced reference at the bottom of my post 
revealed, lol.
Feb 12 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 21:36, schrieb Jakob Ovrum:

 On Wednesday, 12 February 2014 at 20:34:35 UTC, Jakob Ovrum wrote:

 On Wednesday, 12 February 2014 at 20:24:28 UTC, Sönke Ludwig wrote:

 I've reduced it and filed a bug:

 https://d.puremagic.com/issues/show_bug.cgi?id=12144

 It was actually great that this occurred in LuaD, because I suspect
 that I'm possibly hit by the same bug, but my code base is so large
 that it takes over a week to run dustmite on it.


 Wow, well done. Sorry for not including all the relevant information
 right away, might have saved you some time. I was actually putting all
 the information together for the post, but as I saw using --verbose
 that everything *looked* right, I decided to wait and see if it really
 was a problem with Dub first - you were one step ahead of me there.

 Thanks!


 ... which the unreferenced reference at the bottom of my post revealed,
 lol.


Yeah, that helped a lot ;)

No, but overall it went pretty quick, with a little Dustmite help and 
(spoiling the news) the upcoming Dustmite integration into DUB, which 
was also very helpful when reducing the rest by hand.
Feb 12 2014
prev sibling next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
El 12/02/14 09:53, Sönke Ludwig ha escrit:

 The binaries can be found on http://code.dlang.org/download ("Latest preview").


On Debian 7.4 64-bit:

$ dub
dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required
by dub)


No problem on Debian 7.4 32-bit.

-- 
Jordi Sayol
Feb 12 2014
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 16:40, schrieb Jordi Sayol:

 El 12/02/14 09:53, Sönke Ludwig ha escrit:

 The binaries can be found on http://code.dlang.org/download ("Latest preview").


 On Debian 7.4 64-bit:

 $ dub
 dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required
by dub)


 No problem on Debian 7.4 32-bit.


I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit, 
hopefully that works...
Feb 12 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 19:12, schrieb Sönke Ludwig:

 Am 12.02.2014 16:40, schrieb Jordi Sayol:

 El 12/02/14 09:53, Sönke Ludwig ha escrit:

 The binaries can be found on http://code.dlang.org/download ("Latest
 preview").


 On Debian 7.4 64-bit:

 $ dub
 dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found
 (required by dub)


 No problem on Debian 7.4 32-bit.


 I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit,
 hopefully that works...


Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.
Feb 12 2014
next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
El 13/02/14 00:18, Sönke Ludwig ha escrit:

 Am 12.02.2014 19:12, schrieb Sönke Ludwig:

 Am 12.02.2014 16:40, schrieb Jordi Sayol:

 El 12/02/14 09:53, Sönke Ludwig ha escrit:

 The binaries can be found on http://code.dlang.org/download ("Latest
 preview").


 On Debian 7.4 64-bit:

 $ dub
 dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found
 (required by dub)


 No problem on Debian 7.4 32-bit.


 I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit,
 hopefully that works...


 
 Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.
 


It properly runs even on Debian 6 x64. Thanks!

-- 
Jordi Sayol
Feb 12 2014
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2014-02-13 at 00:18 +0100, Sönke Ludwig wrote:
[…]

 Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.


I missed earlier activity, but just downloaded the Linux x86_64
0.9.21-rc3 and it appears to work fine on Debian Sid (Unstable). Except…

…I have no idea what to put in the package.json file to get rid of this
problem:

        source/main.d(27): Error: need -Jpath switch to import text file
        VERSION

http://code.dlang.org/package-format doesn't mention this option.

-J. is all I need given my SCons build of this same project.


-- 
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
Feb 13 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 10:28, schrieb Russel Winder:

 On Thu, 2014-02-13 at 00:18 +0100, Sönke Ludwig wrote:
 […]

 Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.


 I missed earlier activity, but just downloaded the Linux x86_64
 0.9.21-rc3 and it appears to work fine on Debian Sid (Unstable). Except…

 …I have no idea what to put in the package.json file to get rid of this
 problem:

          source/main.d(27): Error: need -Jpath switch to import text file
          VERSION

 http://code.dlang.org/package-format doesn't mention this option.

 -J. is all I need given my SCons build of this same project.


That's the "stringImportPaths" field which corresponds to -J, there 
should probably be a small note to which DMD flag each field corresponds 
(if applicable, of course).
Feb 13 2014
prev sibling next sibling parent reply "extrawurst" <stephan extrawurst.org> writes:
On Wednesday, 12 February 2014 at 23:18:07 UTC, Sönke Ludwig 
wrote:

 Am 12.02.2014 19:12, schrieb Sönke Ludwig:

 Am 12.02.2014 16:40, schrieb Jordi Sayol:

 El 12/02/14 09:53, Sönke Ludwig ha escrit:

 The binaries can be found on http://code.dlang.org/download 
 ("Latest
 preview").


 On Debian 7.4 64-bit:

 $ dub
 dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' 
 not found
 (required by dub)


 No problem on Debian 7.4 32-bit.


 I'll build the next RC with Debian 6 instead of Ubuntu 12.04 
 for 64-bit,
 hopefully that works...


 Okay, uploaded a new version of RC 3 built on Debian 7 x64 
 instead.


I just tried to run dub on Amazon ami linux. Although it runs it 
prints:
dub: /usr/lib64/libcurl.so.4: no version information available 
(required by dub)

Is that a problem ? WOuld it be fixed if I built dub myself there 
?
Feb 13 2014
next sibling parent reply "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
Nice to see the dependencies not having to be compiled over and 
over again. One thing though: It seems dependencies are compiled 
with -m32 and my source with -m64, meaning they have different 
object formats in Windows, and the linker chokes.
Feb 13 2014
next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 11:55, schrieb "Casper Færgemand" <shorttail hotmail.com>":

 Nice to see the dependencies not having to be compiled over and over
 again. One thing though: It seems dependencies are compiled with -m32
 and my source with -m64, meaning they have different object formats in
 Windows, and the linker chokes.


Good catch. I'll look into that.
Feb 13 2014
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 11:55, schrieb "Casper Færgemand" <shorttail hotmail.com>":

 It seems dependencies are compiled with -m32
 and my source with -m64, meaning they have different object formats in
 Windows, and the linker chokes.


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).
Feb 13 2014
parent reply "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
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?
Feb 13 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
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?
Feb 13 2014
parent "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail gmail.com> writes:
On Thursday, 13 February 2014 at 20:39:34 UTC, Sönke Ludwig wrote:

 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?


I'm not sure what would be a good solution, honestly. My trouble 
comes from Vibe.d not supporting 64 bit Windows (at least 
previously) and SIMD not supporting 32 bit Windows, meaning I 
can't set a global switch in the compiler configuration file 
either, but I guess the general use of the switch would be to fit 
the actual architecture and not some silly issue like mine.
I suppose the manual switch will do.
Feb 15 2014
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 11:39, schrieb extrawurst:

 On Wednesday, 12 February 2014 at 23:18:07 UTC, Sönke Ludwig wrote:

 Am 12.02.2014 19:12, schrieb Sönke Ludwig:

 Am 12.02.2014 16:40, schrieb Jordi Sayol:

 El 12/02/14 09:53, Sönke Ludwig ha escrit:

 The binaries can be found on http://code.dlang.org/download ("Latest
 preview").


 On Debian 7.4 64-bit:

 $ dub
 dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found
 (required by dub)


 No problem on Debian 7.4 32-bit.


 I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit,
 hopefully that works...


 Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.


 I just tried to run dub on Amazon ami linux. Although it runs it prints:
 dub: /usr/lib64/libcurl.so.4: no version information available (required
 by dub)

 Is that a problem ? WOuld it be fixed if I built dub myself there ?


libcurl is a dependency of Phobos, so I'm actually not sure. Maybe it's 
necessary to rebuild Phobos, too.
Feb 13 2014
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
I just tried the Linux x86_64 executable on Fedora 20, and it works
except for:

dub: /lib64/libcurl.so.4: no version information available (required by
dub)

I am not entirely sure why it doesn't find:

/usr/lib64/libcurl.so.4
/usr/lib/libcurl.so.4

which are most definitely present.

I also tried the OSX executable on a Mavericks machine and it works
fine, except…

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

There perhaps needs to be a way of dub cleaning the ~/.dub hierarchy,
currently I seem to have to manually search all the dependencies and
clean up. In fact, is there a clean command to dub to clean the project
and the ~/.dub? 

-- 
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
Feb 13 2014
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 12:40, schrieb Russel Winder:

 I just tried the Linux x86_64 executable on Fedora 20, and it works
 except for:

 dub: /lib64/libcurl.so.4: no version information available (required by
 dub)

 I am not entirely sure why it doesn't find:

 /usr/lib64/libcurl.so.4
 /usr/lib/libcurl.so.4

 which are most definitely present.


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.


 I also tried the OSX executable on a Mavericks machine and it works
 fine, except…

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


 There perhaps needs to be a way of dub cleaning the ~/.dub hierarchy,
 currently I seem to have to manually search all the dependencies and
 clean up. In fact, is there a clean command to dub to clean the project
 and the ~/.dub?


There is an enhancement request for this, but it hasn't been 
implemented, yet. What is there, though, is the --force switch for 
forcing a rebuild.
Feb 13 2014
next sibling parent reply "Etienne" <etcimon gmail.com> writes:
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.
Feb 13 2014
parent reply "Etienne" <etcimon gmail.com> writes:
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.
Feb 13 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
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.
Feb 13 2014
parent reply "Etienne" <etcimon gmail.com> writes:
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?
Feb 13 2014
next sibling parent reply "Etienne" <etcimon gmail.com> writes:
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.
Feb 13 2014
parent "Etienne" <etcimon gmail.com> writes:
 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.
Feb 13 2014
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 14.02.2014 01:25, schrieb Etienne:

 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?


Oh okay, I just misunderstood how the spec file works then. I'll just 
change it to use the already checked out source and put it into the 
installer folder [1] then.

Is it possible to make the package version dynamic to match the current 
git tag somehow? For example by using an environment variable or by 
passing the version to rpmbuild?

DEB packages are already kindly maintained by Jordi Sayol, so I can 
leave those out.

[1]: https://github.com/rejectedsoftware/dub/tree/master/installer
Feb 14 2014
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
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
Feb 13 2014
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 13 February 2014 at 11:40:56 UTC, Russel Winder 
wrote:

 I just tried the Linux x86_64 executable on Fedora 20, and it 
 works
 except for:

 dub: /lib64/libcurl.so.4: no version information available 
 (required by
 dub)

 I am not entirely sure why it doesn't find:

 /usr/lib64/libcurl.so.4
 /usr/lib/libcurl.so.4

 which are most definitely present.

 I also tried the OSX executable on a Mavericks machine and it 
 works
 fine, except…

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

 There perhaps needs to be a way of dub cleaning the ~/.dub 
 hierarchy,
 currently I seem to have to manually search all the 
 dependencies and
 clean up. In fact, is there a clean command to dub to clean the 
 project
 and the ~/.dub?


https://github.com/rejectedsoftware/dub/issues/134

In the mean time I would just delete the whole ~/.dub folder 
every time you change OS.
Feb 13 2014
prev sibling parent reply "Etienne Cimon" <etcimon gmail.com> writes:
On Wednesday, 12 February 2014 at 15:40:27 UTC, Jordi Sayol wrote:

 El 12/02/14 09:53, Sönke Ludwig ha escrit:

 The binaries can be found on http://code.dlang.org/download 
 ("Latest preview").


 On Debian 7.4 64-bit:

 $ dub
 dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not 
 found (required by dub)


 No problem on Debian 7.4 32-bit.


You'll find the version of >= GLIBC_2.14 in debian's experimental 
repo in aptitude.

$ sudo vim /etc/apt/sources.list

in this file you can append:

     deb http://ftp.debian.org/debian/ experimental main
     deb-src http://ftp.debian.org/debian/ experimental main

Then you can run
$ sudo apt-get -t experimental update && sudo apt-get -t 
experimental upgrade

You should receive glibc 2.18-* experimental which is >=2.14 i.e. 
compatible with dub 0.9.21

You should also install the most recent version of libevent with

$ sudo apt-cache search libevent-2*

which should return libevent-2.0-5, in which case you can run

$ sudo apt-get libevent-2.0-5 libevent-pthreads-2.0-5 libevent-dev

That should do :)
Feb 12 2014
next sibling parent "Etienne Cimon" <etcimon gmail.com> writes:
It's worth nothing that dub.json runs as a project file in mono-d 
monodevelop IDE as well. Every dependency loads in the project 
tree. So, all in all, with git, autocomplete and everything, it's 
becoming very stable, cross-platform and beautifully integrated. 
It all makes D feel like a convenient programming language to 
use, when even 3 months ago the same dub&mono-d setup was totally 
impossible to use even though it was there. The developers on 
this are so good it seems like there's 1000s of men putting it 
all together.
Feb 12 2014
prev sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
El 13/02/14 05:28, Etienne Cimon ha escrit:

 On Wednesday, 12 February 2014 at 15:40:27 UTC, Jordi Sayol wrote:

 El 12/02/14 09:53, Sönke Ludwig ha escrit:

 The binaries can be found on http://code.dlang.org/download ("Latest preview").


 On Debian 7.4 64-bit:

 $ dub
 dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required
by dub)


 No problem on Debian 7.4 32-bit.


 
 You'll find the version of >= GLIBC_2.14 in debian's experimental repo in
aptitude.
 
 $ sudo vim /etc/apt/sources.list
 
 in this file you can append:
 
     deb http://ftp.debian.org/debian/ experimental main
     deb-src http://ftp.debian.org/debian/ experimental main
 
 Then you can run
 $ sudo apt-get -t experimental update && sudo apt-get -t experimental upgrade
 
 You should receive glibc 2.18-* experimental which is >=2.14 i.e. compatible
with dub 0.9.21
 
 You should also install the most recent version of libevent with
 
 $ sudo apt-cache search libevent-2*
 
 which should return libevent-2.0-5, in which case you can run
 
 $ sudo apt-get libevent-2.0-5 libevent-pthreads-2.0-5 libevent-dev
 
 That should do :)
 


Thank you but this should be done by every Debian 6 or 7 dub user.

The easiest way to fix this is to compile dub on Debian 6 or 7.

Regards,
-- 
Jordi Sayol
Feb 13 2014
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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 :)
Feb 12 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
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).
Feb 13 2014
prev sibling next sibling parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig+dforum outerproduct.org> writes:
Uploaded RC 4 with fixes for the issues encountered so far. If no other 
critical error or regression occurs, this one will go final.
Feb 13 2014
prev sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig+dforum outerproduct.org> writes:
Hopefully the final release candidate has been uploaded. The new RPM 
package could need some testing:

http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
http://code.dlang.org/download
Feb 20 2014
next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
El 20/02/14 17:04, Sönke Ludwig ha escrit:

 Hopefully the final release candidate has been uploaded. The new RPM package
could need some testing:
 
 http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
 http://code.dlang.org/download
 


dub rc5 binaries properly tested on Debian 6.

New rpm package properly tested on Fedora 14, Fedora 18 and OpenSUSE 12.4

Will be a rpm 32-bit version?

-- 
Jordi Sayol
Feb 20 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 20.02.2014 21:38, schrieb Jordi Sayol:

 El 20/02/14 17:04, Sönke Ludwig ha escrit:

 Hopefully the final release candidate has been uploaded. The new RPM package
could need some testing:

 http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
 http://code.dlang.org/download


 dub rc5 binaries properly tested on Debian 6.

 New rpm package properly tested on Fedora 14, Fedora 18 and OpenSUSE 12.4


Thanks a lot for testing! I'll tag this as a release if nothing else 
happens until then.


 Will be a rpm 32-bit version?


Yes, should be no problem, but I'd like to load that off to the next 
version together with an outstanding automation issue (the RPM still 
needs to be uploaded manually in contrast to all the other files) and an 
improved download page layout.
Feb 21 2014
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2014-02-20 at 17:04 +0100, Sönke Ludwig wrote:

 Hopefully the final release candidate has been uploaded. The new RPM 
 package could need some testing:
 
 http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
 http://code.dlang.org/download


The 64-bit Tarball for Linux works for me on Debian Unstable. Haven't
had chance to test other things yet.

-- 
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
Feb 21 2014
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2014-02-21 at 17:40 +0000, Russel Winder wrote:

 On Thu, 2014-02-20 at 17:04 +0100, Sönke Ludwig wrote:

 Hopefully the final release candidate has been uploaded. The new RPM 
 package could need some testing:
 
 http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
 http://code.dlang.org/download


 
 The 64-bit Tarball for Linux works for me on Debian Unstable. Haven't
 had chance to test other things yet.


It also works on Fedora 20, but with the:

dub: /lib64/libcurl.so.4: no version information available (required by
dub)

line. I installed the RPM on Fedora 20 and it it works fine without the
above message.


-- 
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
Feb 22 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 22.02.2014 11:43, schrieb Russel Winder:

 On Fri, 2014-02-21 at 17:40 +0000, Russel Winder wrote:

 On Thu, 2014-02-20 at 17:04 +0100, Sönke Ludwig wrote:

 Hopefully the final release candidate has been uploaded. The new RPM
 package could need some testing:

 http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
 http://code.dlang.org/download


 The 64-bit Tarball for Linux works for me on Debian Unstable. Haven't
 had chance to test other things yet.


 It also works on Fedora 20, but with the:

 dub: /lib64/libcurl.so.4: no version information available (required by
 dub)

 line. I installed the RPM on Fedora 20 and it it works fine without the
 above message.


Thanks for the confirmation, I've just uploaded the final packages.
Feb 22 2014
parent Russel Winder <russel winder.org.uk> writes:
On Sat, 2014-02-22 at 12:22 +0100, Sönke Ludwig wrote:
[…]

 Thanks for the confirmation, I've just uploaded the final packages.


Picked up the new, final release: the RPM works exactly as it should
upgrading the rc5 one.

-- 
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
Feb 22 2014