... as there are so many discussions in the various groups...
maybe this PDF is useful for anything/anyone/something ;)
http://gittup.org/tup/build_system_rules_and_algorithms.pdf
On Wednesday, 24 July 2013 at 12:24:26 UTC, Luís Marques wrote:
I have some old D code and I wanted to improve its build
system: that code was using a .bat and shell script with dmd,
manually listing all the .d files to be linked! Don't ask me
why I didn't use at least a Makefil
On 2013-07-24 14:34, Dicebot wrote:
If code amount is relatively small (and building does not involve
calling any external tools), I'd stick with rdmd.
`rdmd --build-only main.d` and let it figure out
all imports.
I use rdmd as well. I'm using two shell script, one to build the
application a
On Wednesday, 24 July 2013 at 12:24:26 UTC, Luís Marques wrote:
I have some old D code and I wanted to improve its build
system: that code was using a .bat and shell script with dmd,
manually listing all the .d files to be linked! Don't ask me
why I didn't use at least a Makefil
I have some old D code and I wanted to improve its build system:
that code was using a .bat and shell script with dmd, manually
listing all the .d files to be linked! Don't ask me why I didn't
use at least a Makefile, I don't recall, this is quite old code.
What would you curr
On Thursday, 30 May 2013 at 07:50:11 UTC, Timothee Cour wrote:
We should move to a D-based build system to build
dmd/druntime/phobos/d-programming-language/tools.
Reasons, in case it's not obvious:
1) DRY: makefile is full of repetitions
2) cross platform: different makefiles for diff
On Thu, 30 May 2013 16:56:48 -0400
"Jonathan M Davis" wrote:
>
> And while many of us really aren't very good at make
> and find the Makefiles that we have to be rather obtuse, folks that
> are more proficient at make might not think that making the switch to
> a D script would make sense. And I
nd still be
able to reasonably do everything that we need our build system to do. And
while many of us really aren't very good at make and find the Makefiles that we
have to be rather obtuse, folks that are more proficient at make might not
think that making the switch to a D script would ma
On Thu, 30 May 2013 00:49:57 -0700
Timothee Cour wrote:
> We should move to a D-based build system to build
> dmd/druntime/phobos/d-programming-language/tools.
>
> Reasons, in case it's not obvious:
>
> 1) DRY: makefile is full of repetitions
> 2) cross platfor
On Thu, 30 May 2013 06:13:54 -0400
Nick Sabalausky wrote:
> On Thu, 30 May 2013 00:49:57 -0700
> Timothee Cour wrote:
> >
> > Here's how it'd work:
> >
> > 1) a mixed D-based/makefile build that'll work 'from scratch' via
> > bootstrapping:
> > 1a) dmd: first uses a makefile to build dmd+drunt
On Thu, 30 May 2013 00:49:57 -0700
Timothee Cour wrote:
>
> Here's how it'd work:
>
> 1) a mixed D-based/makefile build that'll work 'from scratch' via
> bootstrapping:
> 1a) dmd: first uses a makefile to build dmd+druntime
> 1b) rdmd built from a D file using dmd
> 1c) phobos, d-programming-lan
We should move to a D-based build system to build
dmd/druntime/phobos/d-programming-language/tools.
Reasons, in case it's not obvious:
1) DRY: makefile is full of repetitions
2) cross platform: different makefiles for different architectures are
needed (even win32 vs win64!)
3) safety: mak
On 20-11-2012 09:21, Andrej Mitrovic wrote:
On 11/20/12, Jacob Carlborg wrote:
I think you misunderstood what I was trying to say, or I am
misunderstanding you.
I'm showing the path of least resistance for how to build either
dmd/druntime/phobos/dlang-org
One solution that instantly pops in
On 2012-11-20 09:21, Andrej Mitrovic wrote:
I'm showing the path of least resistance for how to build either
dmd/druntime/phobos/dlang-org
The build systems for the repositories are still breaking out of their
top level directory.
They are buggy on Windows. The last time I've used them Git
On 11/20/12, Jacob Carlborg wrote:
> I think you misunderstood what I was trying to say, or I am
> misunderstanding you.
I'm showing the path of least resistance for how to build either
dmd/druntime/phobos/dlang-org
> One solution that instantly pops in my mind is using git submodules.
They are
sterton's fence fallacy.
One solution that instantly pops in my mind is using git submodules.
Create a new repository, say "dlang", add the other repositories as git
submoduels to "dlang". Then the build system can do whatever it wants in
the "dlang" directory and
On 2012-11-19 11:34, Andrej Mitrovic wrote:
Well on win32 I have two directories on my drive, "dmd" and "dmd-git".
"dmd" is an official release, while "dmd-git" is git-head. The dir
structure is:
dmd-git\dmd2\src\dmd <- git-head
dmd-git\dmd2\src\druntime <- git-head
dmd-git\dmd2\src\phobos <-
On 11/19/12 3:29 AM, Jacob Carlborg wrote:
Is it just me that thinks the build system of D (DMD, Phobos, druntime,
and so on) is really annoying. I'm mostly thinking of the directory
structure that the makefiles expect.
For example, when building Phobos it will also, automatically,
On 11/19/12, Jacob Carlborg wrote:
> Is it just me that thinks the build system of D (DMD, Phobos, druntime,
> and so on) is really annoying. I'm mostly thinking of the directory
> structure that the makefiles expect.
Well on win32 I have two directories on my drive, "dmd&q
Is it just me that thinks the build system of D (DMD, Phobos, druntime,
and so on) is really annoying. I'm mostly thinking of the directory
structure that the makefiles expect.
For example, when building Phobos it will also, automatically, build
druntime, which it expects to find i
On 2011-11-05 14:55, Marco Leise wrote:
I disagree. Maven is an example of a tool that does all-in-one (even a
lot more than package management and compiling) and it doesn't hurt. I
don't want to find, download and install a compiler, a package manager
and a build tool for the majority of build t
On 2011-11-05 14:47, Marco Leise wrote:
Am 05.11.2011, 13:52 Uhr, schrieb Marco Leise :
Am 26.10.2011, 20:52 Uhr, schrieb Jacob Carlborg :
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
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
Am 26.10.2011, 20:43 Uhr, schrieb Gor Gyolchanyan
:
I agree.
On Wed, Oct 26, 2011 at 10:35 PM, Jacob Carlborg wrote:
On 2011-10-26 15:39, Martin Nowak wrote:
On Wed, 26 Oct 2011 12:26:56 +0200, Gor Gyolchanyan
wrote:
I had a few thoughts about integrating build awareness into DMD.
It w
Am 05.11.2011, 13:52 Uhr, schrieb Marco Leise :
Am 26.10.2011, 20:52 Uhr, schrieb Jacob Carlborg :
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
braries (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/or
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
>> 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.
Totally. :-)
On Thu, Oct 27, 2011 at 3:27 AM, bearophile 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 modul
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 t
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!!!
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
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/project
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 co
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 ma
ven'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 th
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 awe
I agree.
On Wed, Oct 26, 2011 at 10:35 PM, Jacob Carlborg wrote:
> On 2011-10-26 15:39, Martin Nowak wrote:
>>
>> On Wed, 26 Oct 2011 12:26:56 +0200, 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
On 2011-10-26 15:39, Martin Nowak wrote:
On Wed, 26 Oct 2011 12:26:56 +0200, 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 awes
On 2011-10-26 15:39, Martin Nowak wrote:
On Wed, 26 Oct 2011 12:26:56 +0200, 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 awes
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 co
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
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 t
t 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.
>
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 b
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, Je
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
This is so cool!!! Package modules have two important roles now:
* Defining the proper imports for the package.
* Defining building rules for the package.
I don't have any particular thoughts about import path and build info
definitions, but I'm certain, that the build rules of parent package
shou
On Wed, 26 Oct 2011 12:26:56 +0200, 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
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 wrote:
> On 2011-10-26 12:26, Gor Gyolchanyan wro
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
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 doc
On 2011-07-14 23:16, Nick Sabalausky wrote:
"Jacob Carlborg" wrote in message
news:ivniga$2lt$1...@digitalmars.com...
On 2011-07-14 08:48, Russel Winder wrote:
On Wed, 2011-07-13 at 20:32 +0200, Jacob Carlborg wrote:
[ . . . ]
I think that one of the problem with these language independent bu
"Jacob Carlborg" wrote in message
news:ivniga$2lt$1...@digitalmars.com...
> On 2011-07-14 08:48, Russel Winder wrote:
>> On Wed, 2011-07-13 at 20:32 +0200, Jacob Carlborg wrote:
>> [ . . . ]
>>> I think that one of the problem with these language independent build
>>> tools is that they don't mak
On 2011-07-14 08:48, Russel Winder wrote:
On Wed, 2011-07-13 at 20:32 +0200, Jacob Carlborg wrote:
[ . . . ]
I think that one of the problem with these language independent build
tools is that they don't make it as easy as it could, because they
usually don't know enough about a given language.
On Wed, 2011-07-13 at 20:32 +0200, Jacob Carlborg wrote:
[ . . . ]
> I think that one of the problem with these language independent build
> tools is that they don't make it as easy as it could, because they
> usually don't know enough about a given language.
This is generally due to incomplete
On 2011-07-13 19:18, Russel Winder wrote:
On Wed, 2011-07-13 at 17:33 +0200, Jacob Carlborg wrote:
target("main.d"); // builds "main.d" as an executable
The SCons equivalent is:
Program ( 'main.d' )
Or:
target("foobar"); // builds the directory "foobar" as a library
SCons (and I
On Wed, 2011-07-13 at 17:33 +0200, Jacob Carlborg wrote:
> target("main.d"); // builds "main.d" as an executable
The SCons equivalent is:
Program ( 'main.d' )
> Or:
>
> target("foobar"); // builds the directory "foobar" as a library
SCons (and I think Waf as well) does not support thi
58 matches
Mail list logo
