www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - build system

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I had a few thoughts about integrating build awareness into DMD.
It would be really cool to add a flag to DMD to make it compile and
link in all import-referenced modules.
Also, it would be awesome to store basic build information in modules
themselves in the form of special comments (much like documentation
comments), where one could specify external build dependencies, output
type, etc.
There would be no need for makefiles and extra build systems. You'd
just feed an arbitrary module to the compiler and the compiler would
build the target, to which that module belongs (bu parsing build
comments and package hierarchies).
Wouldn't this be a good thing to have?
Oct 26 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-10-26 12:26, Gor Gyolchanyan wrote:

 I had a few thoughts about integrating build awareness into DMD.
 It would be really cool to add a flag to DMD to make it compile and
 link in all import-referenced modules.
 Also, it would be awesome to store basic build information in modules
 themselves in the form of special comments (much like documentation
 comments), where one could specify external build dependencies, output
 type, etc.
 There would be no need for makefiles and extra build systems. You'd
 just feed an arbitrary module to the compiler and the compiler would
 build the target, to which that module belongs (bu parsing build
 comments and package hierarchies).
 Wouldn't this be a good thing to have?


Sounds horrible to have a build script in comments in the source code. I 
think the right approach is to have a separate build tool, with a proper 
DSL built on an existing language, e.g. Ruby, D, something else.

There are already a couple of build tools available:

DSSS - D1 only, not maintained any more
xfbuild - Probably not maintained any more. No build script
rdmd - Cannot build libraries, no build script, cannot do much besides 
from building executables

I've been working on a build tool, https://bitbucket.org/doob/dake . 
I've started rewriting the tool in D, been a while since I worked on it. 
Currently it's not a prioritized project for me.

I also know others are working on built tools for D.

-- 
/Jacob Carlborg
Oct 26 2011
next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
That's the problem - no working build tool exists for D.
Why don't you like the idea of integrating build information in source
code? I mean, that information does not change for a given source
file.

On Wed, Oct 26, 2011 at 3:37 PM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-26 12:26, Gor Gyolchanyan wrote:

 I had a few thoughts about integrating build awareness into DMD.
 It would be really cool to add a flag to DMD to make it compile and
 link in all import-referenced modules.
 Also, it would be awesome to store basic build information in modules
 themselves in the form of special comments (much like documentation
 comments), where one could specify external build dependencies, output
 type, etc.
 There would be no need for makefiles and extra build systems. You'd
 just feed an arbitrary module to the compiler and the compiler would
 build the target, to which that module belongs (bu parsing build
 comments and package hierarchies).
 Wouldn't this be a good thing to have?


 Sounds horrible to have a build script in comments in the source code. I
 think the right approach is to have a separate build tool, with a proper DSL
 built on an existing language, e.g. Ruby, D, something else.

 There are already a couple of build tools available:

 DSSS - D1 only, not maintained any more
 xfbuild - Probably not maintained any more. No build script
 rdmd - Cannot build libraries, no build script, cannot do much besides from
 building executables

 I've been working on a build tool, https://bitbucket.org/doob/dake . I've
 started rewriting the tool in D, been a while since I worked on it.
 Currently it's not a prioritized project for me.

 I also know others are working on built tools for D.

 --
 /Jacob Carlborg
Oct 26 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-10-26 13:44, Gor Gyolchanyan wrote:

 That's the problem - no working build tool exists for D.
 Why don't you like the idea of integrating build information in source
 code? I mean, that information does not change for a given source
 file.


* The compiler should only do one thing: compile code

* I think the best approach would be to have a complete language for the 
build scripts. Should the compiler now start to parse comments as well 
for finding code? How would it tell the difference between a build 
script and some arbitrary code that is commented out.

* I think that it would be good if if you could invoke arbitrary 
tasks/actions (think make, rake) using the build tool and that's not 
what a compiler should do

* If the build script adds import paths you have to make sure that the 
source file containing the build script always is handle first by the 
compiler

* It's just ugly

-- 
/Jacob Carlborg
Oct 26 2011
next sibling parent reply "Eric Poggel (JoeCoder)" <dnewsgroup2 yage3d.net> writes:
On 10/26/2011 2:30 PM, Jacob Carlborg wrote:

 I think the best approach would be to have a complete language for the
 build scripts.


This is the approach I've taken with dsource.org/projects/cdc.  That 
language is D.  It provides a library of common compilation tasks and 
then you fill in the main() with what you want it to do.  Then you can 
simply invoke dmd -run buildscript.d to create your project.

At one point it worked with d1 and d2 with ldc, gdc, and dmd, phobos or 
tango.  But it's been a year or so since I've tested.

It can also be used as a pass-through tool to dmd, gdc, or ldc, except 
it accepts source paths as well as source files (adding all files in the 
path to the build).  But rdmd may already do this better, since cdc 
currently lacks any concept of an incremental build.
Oct 26 2011
parent reply "Eric Poggel (JoeCoder)" <dnewsgroup2 yage3d.net> writes:
On 10/26/2011 2:51 PM, Eric Poggel (JoeCoder) wrote:

 On 10/26/2011 2:30 PM, Jacob Carlborg wrote:

 I think the best approach would be to have a complete language for the
 build scripts.


 This is the approach I've taken with dsource.org/projects/cdc. That
 language is D. It provides a library of common compilation tasks and
 then you fill in the main() with what you want it to do. Then you can
 simply invoke dmd -run buildscript.d to create your project.

 At one point it worked with d1 and d2 with ldc, gdc, and dmd, phobos or
 tango. But it's been a year or so since I've tested.

 It can also be used as a pass-through tool to dmd, gdc, or ldc, except
 it accepts source paths as well as source files (adding all files in the
 path to the build). But rdmd may already do this better, since cdc
 currently lacks any concept of an incremental build.



But my point here isn't so much to promote CDC, bur rather to insist 
that we should use D instead of a custom language invented for the task. 
  Reasons:

1.  D will always be more powerful.  And you will have all of phobos at 
your disposal.  You can parse xml, ftp files, etc.
2.  Anyone writing this script will already know D.  They won't have to 
learn another language.
3.  We'll truly be eating our own dog food.  Although I wouldn't call it 
dog food.
Oct 26 2011
parent reply "Eric Poggel (JoeCoder)" <dnewsgroup2 yage3d.net> writes:
On 10/26/2011 2:55 PM, Eric Poggel (JoeCoder) wrote:

 On 10/26/2011 2:51 PM, Eric Poggel (JoeCoder) wrote:

 On 10/26/2011 2:30 PM, Jacob Carlborg wrote:

 I think the best approach would be to have a complete language for the
 build scripts.


 This is the approach I've taken with dsource.org/projects/cdc. That
 language is D. It provides a library of common compilation tasks and
 then you fill in the main() with what you want it to do. Then you can
 simply invoke dmd -run buildscript.d to create your project.

 At one point it worked with d1 and d2 with ldc, gdc, and dmd, phobos or
 tango. But it's been a year or so since I've tested.

 It can also be used as a pass-through tool to dmd, gdc, or ldc, except
 it accepts source paths as well as source files (adding all files in the
 path to the build). But rdmd may already do this better, since cdc
 currently lacks any concept of an incremental build.



 But my point here isn't so much to promote CDC, bur rather to insist
 that we should use D instead of a custom language invented for the task.
 Reasons:

 1. D will always be more powerful. And you will have all of phobos at
 your disposal. You can parse xml, ftp files, etc.
 2. Anyone writing this script will already know D. They won't have to
 learn another language.
 3. We'll truly be eating our own dog food. Although I wouldn't call it
 dog food.


4.  It will be easier to implement.  A library of functions instead of a 
complete parser/interpreter.  CDC is boost licensed if anyone wants to 
borrow from it.
Oct 26 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-10-26 20:57, Eric Poggel (JoeCoder) wrote:

 On 10/26/2011 2:55 PM, Eric Poggel (JoeCoder) wrote:

 On 10/26/2011 2:51 PM, Eric Poggel (JoeCoder) wrote:

 On 10/26/2011 2:30 PM, Jacob Carlborg wrote:

 I think the best approach would be to have a complete language for the
 build scripts.


 This is the approach I've taken with dsource.org/projects/cdc. That
 language is D. It provides a library of common compilation tasks and
 then you fill in the main() with what you want it to do. Then you can
 simply invoke dmd -run buildscript.d to create your project.

 At one point it worked with d1 and d2 with ldc, gdc, and dmd, phobos or
 tango. But it's been a year or so since I've tested.

 It can also be used as a pass-through tool to dmd, gdc, or ldc, except
 it accepts source paths as well as source files (adding all files in the
 path to the build). But rdmd may already do this better, since cdc
 currently lacks any concept of an incremental build.



 But my point here isn't so much to promote CDC, bur rather to insist
 that we should use D instead of a custom language invented for the task.
 Reasons:

 1. D will always be more powerful. And you will have all of phobos at
 your disposal. You can parse xml, ftp files, etc.
 2. Anyone writing this script will already know D. They won't have to
 learn another language.
 3. We'll truly be eating our own dog food. Although I wouldn't call it
 dog food.


 4. It will be easier to implement. A library of functions instead of a
 complete parser/interpreter. CDC is boost licensed if anyone wants to
 borrow from it.


I'm using Ruby for my package manger Orbit, it's working very well. It 
allows, in my opinion, a cleaner and better looking DSL than D.

-- 
/Jacob Carlborg
Oct 26 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jacob Carlborg:


 * The compiler should only do one thing: compile code


Currently DMD "fails" at this, because it also performs profiling, coverage
analysis, unittest runner system, documentation files creator, JSON module
description files creator, it prints dependencies on request, it calls the
linker, and probably it does something more I am forgetting :-)

Bye,
bearophile
Oct 26 2011
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Totally. :-)

On Thu, Oct 27, 2011 at 3:27 AM, bearophile <bearophileHUGS lycos.com> wrot=
e:

 Jacob Carlborg:


 * The compiler should only do one thing: compile code


 Currently DMD "fails" at this, because it also performs profiling, covera=


ge analysis, unittest runner system, documentation files creator, JSON modu=
le description files creator, it prints dependencies on request, it calls t=
he linker, and probably it does something more I am forgetting :-)

 Bye,
 bearophile
Oct 26 2011
parent reply mta`chrono <chrono mta-international.net> writes:
Am 27.10.2011 01:43, schrieb Gor Gyolchanyan:

 Totally. :-)
 
 On Thu, Oct 27, 2011 at 3:27 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Jacob Carlborg:


 * The compiler should only do one thing: compile code


 Currently DMD "fails" at this, because it also performs profiling, coverage
analysis, unittest runner system, documentation files creator, JSON module
description files creator, it prints dependencies on request, it calls the
linker, and probably it does something more I am forgetting :-)

 Bye,
 bearophile




how do you archieve to compile on 4 cores at the same time? dmd invokes
it self? worker threads in dmd so that it can compile multiple files at
the same time? I think the build system shouldn't be included in the
compiler.
Oct 26 2011
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Just because it isn't easy to imagine right away doesn't mean it shouldn't.

On Thu, Oct 27, 2011 at 10:29 AM, mta`chrono
<chrono mta-international.net> wrote:

 Am 27.10.2011 01:43, schrieb Gor Gyolchanyan:

 Totally. :-)

 On Thu, Oct 27, 2011 at 3:27 AM, bearophile <bearophileHUGS lycos.com> w=




rote:

 Jacob Carlborg:


 * The compiler should only do one thing: compile code


 Currently DMD "fails" at this, because it also performs profiling, cove=






rage analysis, unittest runner system, documentation files creator, JSON mo=
dule description files creator, it prints dependencies on request, it calls=
 the linker, and probably it does something more I am forgetting :-)

 Bye,
 bearophile




 how do you archieve to compile on 4 cores at the same time? dmd invokes
 it self? worker threads in dmd so that it can compile multiple files at
 the same time? I think the build system shouldn't be included in the
 compiler.
Oct 27 2011
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, October 26, 2011 04:44 Gor Gyolchanyan wrote:

 That's the problem - no working build tool exists for D.
 Why don't you like the idea of integrating build information in source
 code? I mean, that information does not change for a given source
 file.


That's just plain messy. And the code that's actually imported could depend on 
compiler flags (such as which import directories are given), allowing you to 
swap out implementations and the like. Hard coding stuff in the source file 
would harm that and IMHO would just clutter the source file.

- Jonathan M Davis
Oct 26 2011
prev sibling next sibling parent reply Jesse Phillips <jessekphillips+d gmail.com> writes:
On Wed, 26 Oct 2011 14:26:56 +0400, Gor Gyolchanyan wrote:


 I had a few thoughts about integrating build awareness into DMD.
 It would be really cool to add a flag to DMD to make it compile and link
 in all import-referenced modules.
 Also, it would be awesome to store basic build information in modules
 themselves in the form of special comments (much like documentation
 comments), where one could specify external build dependencies, output
 type, etc.
 There would be no need for makefiles and extra build systems. You'd just
 feed an arbitrary module to the compiler and the compiler would build
 the target, to which that module belongs (bu parsing build comments and
 package hierarchies).
 Wouldn't this be a good thing to have?


Do you know about rdmd and pragma(lib,...) ?
Oct 26 2011
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Obviously. I'm using rdmd currently, because my work primarily
consists of research and i didn't collect a large enough code base.
It's not fit for building lots of targets from a big code base.
pragma(lib, ...) is the tip of the iceberg, that I'm talking about.

On Wed, Oct 26, 2011 at 6:27 PM, Jesse Phillips
<jessekphillips+d gmail.com> wrote:

 On Wed, 26 Oct 2011 14:26:56 +0400, Gor Gyolchanyan wrote:


 I had a few thoughts about integrating build awareness into DMD.
 It would be really cool to add a flag to DMD to make it compile and link
 in all import-referenced modules.
 Also, it would be awesome to store basic build information in modules
 themselves in the form of special comments (much like documentation
 comments), where one could specify external build dependencies, output
 type, etc.
 There would be no need for makefiles and extra build systems. You'd just
 feed an arbitrary module to the compiler and the compiler would build
 the target, to which that module belongs (bu parsing build comments and
 package hierarchies).
 Wouldn't this be a good thing to have?


 Do you know about rdmd and pragma(lib,...) ?
Oct 26 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-10-26 16:27, Jesse Phillips wrote:

 On Wed, 26 Oct 2011 14:26:56 +0400, Gor Gyolchanyan wrote:


 I had a few thoughts about integrating build awareness into DMD.
 It would be really cool to add a flag to DMD to make it compile and link
 in all import-referenced modules.
 Also, it would be awesome to store basic build information in modules
 themselves in the form of special comments (much like documentation
 comments), where one could specify external build dependencies, output
 type, etc.
 There would be no need for makefiles and extra build systems. You'd just
 feed an arbitrary module to the compiler and the compiler would build
 the target, to which that module belongs (bu parsing build comments and
 package hierarchies).
 Wouldn't this be a good thing to have?


 Do you know about rdmd and pragma(lib,...) ?


RDMD can only build binaries and... well, that's about it.

-- 
/Jacob Carlborg
Oct 26 2011
prev sibling parent reply jsternberg <jonathansternberg gmail.com> writes:
Gor Gyolchanyan Wrote:


 I had a few thoughts about integrating build awareness into DMD.
 It would be really cool to add a flag to DMD to make it compile and
 link in all import-referenced modules.
 Also, it would be awesome to store basic build information in modules
 themselves in the form of special comments (much like documentation
 comments), where one could specify external build dependencies, output
 type, etc.
 There would be no need for makefiles and extra build systems. You'd
 just feed an arbitrary module to the compiler and the compiler would
 build the target, to which that module belongs (bu parsing build
 comments and package hierarchies).
 Wouldn't this be a good thing to have?


Take a look at Cabal and ghc-pkg/ghc --make from Haskell. I've been thinking
about starting to put together something like this, but I haven't found the
motivation to do it. This type of package management and build integration
would go a long way to making D less decentralized.

One thing that would be needed to complete such a system is proper support for
linking shared libraries (at least on Linux).

There are a bunch of things the build system could do that would make
development in D much easier.

If you're interested in doing this, you should contact me on the IRC channel.
Oct 26 2011
next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I'm certainly interested in doing it, but I'm not familiar with that
IRC channel of yours.
If you need me, here's my skype: gor_f_gyolchanyan. Please mention
digitalmatrs-d puremagic.com if you decide to sent an authorization
request.
I'm almost always available.

On Wed, Oct 26, 2011 at 8:01 PM, jsternberg <jonathansternberg gmail.com> w=
rote:

 Gor Gyolchanyan Wrote:


 I had a few thoughts about integrating build awareness into DMD.
 It would be really cool to add a flag to DMD to make it compile and
 link in all import-referenced modules.
 Also, it would be awesome to store basic build information in modules
 themselves in the form of special comments (much like documentation
 comments), where one could specify external build dependencies, output
 type, etc.
 There would be no need for makefiles and extra build systems. You'd
 just feed an arbitrary module to the compiler and the compiler would
 build the target, to which that module belongs (bu parsing build
 comments and package hierarchies).
 Wouldn't this be a good thing to have?


 Take a look at Cabal and ghc-pkg/ghc --make from Haskell. I've been think=


ing about starting to put together something like this, but I haven't found=
 the motivation to do it. This type of package management and build integra=
tion would go a long way to making D less decentralized.

 One thing that would be needed to complete such a system is proper suppor=


t for linking shared libraries (at least on Linux).

 There are a bunch of things the build system could do that would make dev=


elopment in D much easier.

 If you're interested in doing this, you should contact me on the IRC chan=


nel.





 Oct 26 2011



  parent  jsternberg <jonathansternberg gmail.com>  writes:


It's the #d channel on irc.freenode.net. I should have been more specific.

Gor Gyolchanyan Wrote:


 I'm certainly interested in doing it, but I'm not familiar with that
 IRC channel of yours.
 If you need me, here's my skype: gor_f_gyolchanyan. Please mention
 digitalmatrs-d puremagic.com if you decide to sent an authorization
 request.
 I'm almost always available.
 
 On Wed, Oct 26, 2011 at 8:01 PM, jsternberg <jonathansternberg gmail.com>
wrote:

 Gor Gyolchanyan Wrote:


 I had a few thoughts about integrating build awareness into DMD.
 It would be really cool to add a flag to DMD to make it compile and
 link in all import-referenced modules.
 Also, it would be awesome to store basic build information in modules
 themselves in the form of special comments (much like documentation
 comments), where one could specify external build dependencies, output
 type, etc.
 There would be no need for makefiles and extra build systems. You'd
 just feed an arbitrary module to the compiler and the compiler would
 build the target, to which that module belongs (bu parsing build
 comments and package hierarchies).
 Wouldn't this be a good thing to have?


 Take a look at Cabal and ghc-pkg/ghc --make from Haskell. I've been thinking
about starting to put together something like this, but I haven't found the
motivation to do it. This type of package management and build integration
would go a long way to making D less decentralized.

 One thing that would be needed to complete such a system is proper support for
linking shared libraries (at least on Linux).

 There are a bunch of things the build system could do that would make
development in D much easier.

 If you're interested in doing this, you should contact me on the IRC channel.







 Oct 26 2011



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-10-26 18:01, jsternberg wrote:

 Gor Gyolchanyan Wrote:


 I had a few thoughts about integrating build awareness into DMD.
 It would be really cool to add a flag to DMD to make it compile and
 link in all import-referenced modules.
 Also, it would be awesome to store basic build information in modules
 themselves in the form of special comments (much like documentation
 comments), where one could specify external build dependencies, output
 type, etc.
 There would be no need for makefiles and extra build systems. You'd
 just feed an arbitrary module to the compiler and the compiler would
 build the target, to which that module belongs (bu parsing build
 comments and package hierarchies).
 Wouldn't this be a good thing to have?


 Take a look at Cabal and ghc-pkg/ghc --make from Haskell. I've been thinking
about starting to put together something like this, but I haven't found the
motivation to do it. This type of package management and build integration
would go a long way to making D less decentralized.

 One thing that would be needed to complete such a system is proper support for
linking shared libraries (at least on Linux).

 There are a bunch of things the build system could do that would make
development in D much easier.

 If you're interested in doing this, you should contact me on the IRC channel.


I'm working on a package manager:

https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
https://github.com/jacob-carlborg/orbit

-- 
/Jacob Carlborg



 Oct 26 2011



 next sibling parent  mta`chrono <chrono mta-international.net>  writes:


With simple makefiles you can compile .c, .cpp and .d, link them
alltogether to a single executable, pass -j 4 to boost it up, strip the
result, have different targets for doc generation, .... yeha :-)

But please replace the odd "make.exe" on windows with gnu's version of
make!!!



 Oct 26 2011



prev sibling  parent reply "Marco Leise" <Marco.Leise gmx.de>  writes:


Am 26.10.2011, 20:52 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2011-10-26 18:01, jsternberg wrote:

 Gor Gyolchanyan Wrote:


 I had a few thoughts about integrating build awareness into DMD.
 It would be really cool to add a flag to DMD to make it compile and
 link in all import-referenced modules.
 Also, it would be awesome to store basic build information in modules
 themselves in the form of special comments (much like documentation
 comments), where one could specify external build dependencies, output
 type, etc.
 There would be no need for makefiles and extra build systems. You'd
 just feed an arbitrary module to the compiler and the compiler would
 build the target, to which that module belongs (bu parsing build
 comments and package hierarchies).
 Wouldn't this be a good thing to have?


 Take a look at Cabal and ghc-pkg/ghc --make from Haskell. I've been  
 thinking about starting to put together something like this, but I  
 haven't found the motivation to do it. This type of package management  
 and build integration would go a long way to making D less  
 decentralized.

 One thing that would be needed to complete such a system is proper  
 support for linking shared libraries (at least on Linux).

 There are a bunch of things the build system could do that would make  
 development in D much easier.

 If you're interested in doing this, you should contact me on the IRC  
 channel.


 I'm working on a package manager:

 https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
 https://github.com/jacob-carlborg/orbit


I'll check it out now. Maybe it can already do some basic compile jobs. At  
least it seems like you really don't want 'Orbit' to go unnoticed ;)



 Nov 05 2011



 next sibling parent reply "Marco Leise" <Marco.Leise gmx.de>  writes:


Am 05.11.2011, 13:52 Uhr, schrieb Marco Leise <Marco.Leise gmx.de>:


 Am 26.10.2011, 20:52 Uhr, schrieb Jacob Carlborg <doob me.com>:

 I'm working on a package manager:

 https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
 https://github.com/jacob-carlborg/orbit


 I'll check it out now. Maybe it can already do some basic compile jobs.  
 At least it seems like you really don't want 'Orbit' to go unnoticed ;)


It took me a while to notice the D2 branch, but I still couldn't get it to  
compile. I installed Ruby, but not DSSS - the dsss.conf seemed simple  
enough, although you have a hardcoded directory to the latest (hard-masked  
in Gentoo) ruby library in it. I just passed all .d files to dmd, but it  
found a missing method return type in line 28 in Zip.d and tried to import  
some non-existent Tango files. That's where I stopped trying.
On Linux I'm used to running ./configure and then type make and I'm done  
--> If Ruby 1.9 isn't installed it should fall back to ruby18-static.a.  
and there should be no hard-coded path to it. Also I would prefer if DSSS  
or Tango weren't used in a D2 project simply because they are not  
up-to-date. On Windows you can expect people to install a precompiled  
binary, but not so much on Linux. So it would help Orbit's popularity if  
it could be compiled from source without much of a hassle :)

- Marco



 Nov 05 2011



  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-11-05 14:47, Marco Leise wrote:

 Am 05.11.2011, 13:52 Uhr, schrieb Marco Leise <Marco.Leise gmx.de>:


 Am 26.10.2011, 20:52 Uhr, schrieb Jacob Carlborg <doob me.com>:

 I'm working on a package manager:

 https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
 https://github.com/jacob-carlborg/orbit


 I'll check it out now. Maybe it can already do some basic compile
 jobs. At least it seems like you really don't want 'Orbit' to go
 unnoticed ;)


 It took me a while to notice the D2 branch, but I still couldn't get it
 to compile. I installed Ruby, but not DSSS - the dsss.conf seemed simple
 enough, although you have a hardcoded directory to the latest
 (hard-masked in Gentoo) ruby library in it. I just passed all .d files
 to dmd, but it found a missing method return type in line 28 in Zip.d
 and tried to import some non-existent Tango files. That's where I
 stopped trying.
 On Linux I'm used to running ./configure and then type make and I'm done
 --> If Ruby 1.9 isn't installed it should fall back to ruby18-static.a.
 and there should be no hard-coded path to it. Also I would prefer if
 DSSS or Tango weren't used in a D2 project simply because they are not
 up-to-date. On Windows you can expect people to install a precompiled
 binary, but not so much on Linux. So it would help Orbit's popularity if
 it could be compiled from source without much of a hassle :)

 - Marco


It's not quite ready to be used by other people yet. I haven't worked on 
the D2 branch for a while, I was just trying out how well it would work 
with D2 and Phobos. It didn't work out that well. The project still uses 
D1 and Tango for the simple reason that I think that Tango is a better 
library than Phobos. No easy way of doing networking with Phobos, no 
cryptographic package and so on.

If you want to try it out use the master branch, D1 and Tango. You can 
compile it with the "build.sh" shell script, no hard coded paths.

You can easily install D1 and Tango using DVM: 
https://bitbucket.org/doob/dvm

-- 
/Jacob Carlborg



 Nov 06 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-11-05 13:52, Marco Leise wrote:

 Am 26.10.2011, 20:52 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2011-10-26 18:01, jsternberg wrote:

 Gor Gyolchanyan Wrote:


 I had a few thoughts about integrating build awareness into DMD.
 It would be really cool to add a flag to DMD to make it compile and
 link in all import-referenced modules.
 Also, it would be awesome to store basic build information in modules
 themselves in the form of special comments (much like documentation
 comments), where one could specify external build dependencies, output
 type, etc.
 There would be no need for makefiles and extra build systems. You'd
 just feed an arbitrary module to the compiler and the compiler would
 build the target, to which that module belongs (bu parsing build
 comments and package hierarchies).
 Wouldn't this be a good thing to have?


 Take a look at Cabal and ghc-pkg/ghc --make from Haskell. I've been
 thinking about starting to put together something like this, but I
 haven't found the motivation to do it. This type of package
 management and build integration would go a long way to making D less
 decentralized.

 One thing that would be needed to complete such a system is proper
 support for linking shared libraries (at least on Linux).

 There are a bunch of things the build system could do that would make
 development in D much easier.

 If you're interested in doing this, you should contact me on the IRC
 channel.


 I'm working on a package manager:

 https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
 https://github.com/jacob-carlborg/orbit


 I'll check it out now. Maybe it can already do some basic compile jobs.
 At least it seems like you really don't want 'Orbit' to go unnoticed ;)


It can do a couple of operations (checkout the cucumber features/tests), 
so far only for local repositories. Well people are always complaining 
about there's no package manager for D, I just want to let people know 
that I'm working on one.

-- 
/Jacob Carlborg



 Nov 06 2011