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
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 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
prev sibling next sibling parent 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
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
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 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 next 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
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 next 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
prev sibling 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 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=

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=

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

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


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 next 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 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=

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
prev sibling next sibling 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=


 Jacob Carlborg:

 * The compiler should only do one thing: compile code

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



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 next sibling parent "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
prev sibling parent "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