ANN: bud/build updated for D2
I updated bud/build to compile with D2. I tested it on Mac OSX 10.6.3 and on Linux, both x86_64. I haven't tried it on windows. I couldn't reach Derek Parnell by email, and so I attached a source tarball to the main wiki page. It was tested with dmd2.0.52. The link is here: http://www.dsource.org/projects/build/attachment/wiki/WikiStart/bud-3-1.04-ported-to-D2.tar.gz?format=raw I'm not the maintainer for this, and I'm new to D so I may not be much help if it doesn't work. But the port seems to work for me, so I'm offering it just in case it helps you. - J
Re: Pretty please: Named arguments
I find this an interesting discussion. Coming from writing alot of code in language that makes extensive and highly effective use of named arguments (R), I can say that optional named arguments (as in Lisp, and descendants like Python and R) do have big software engineering benefits, but also come with a substantial costs in terms of complexity of the function call sequence. That is, named arguments can be expensive in a typical interpreted implementation (probably one reason why R and Python are much slower to execute than the other interpreted languages), presumably because each function call has to invoke hash table lookups to determine the canonical formal position of each actual argument, and deal with variadic cases, to rearrange the order of the arguments to match expectations of the callee. Someone familiar with lisp compilers could probably tell you if the heavy speed tax is intrinsic or just the price of interpretation. It would indeed be an interesting challenge to see if the compile-time metaprogramming features of D would allow one to include named arguments in an opt-in fashion without speed reduction. Jason On Wed, Mar 2, 2011 at 6:16 AM, Don wrote: > Jim wrote: > >> Jonathan M Davis Wrote: >> >> On Tuesday, March 01, 2011 11:22:17 Bekenn wrote: >>> On 2/28/11 1:38 PM, Don wrote: > 1. It makes parameter names part of the API. > I wrote earlier that this would probably be the first time parameter names "leaked" into user code, but I was wrong. Jacob Carlborg has pointed out his library implementation of this feature: http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135 If you look through his implementation, you'll see that it uses the .stringof property to extract parameter names from the function definition. In essence, parameter names are /already/ part of the API, because code can be written that depends on them. And the fact that a library implementation exists specifically to facilitate the use of named arguments implies that code already /has/ been written that depends on parameter names. Like it or not, parameter names are already part of the API. Adding named arguments as a language feature doesn't change that. >>> You're talking about a third party library that's trying to hack in named >>> arguments, not the language nor the standard library. >>> >>> The parameter names of a function are _not_ currently part of its >>> signature. You could have a .di file without any parameter names or with >>> totally different parameter names than the original .d file and it would >>> have _zero_ effect on anything calling those functions. The function >>> signature does _not_ include the name of its parameters - just their types. >>> Adding named arguments would change that. >>> >>> - Jonathan M Davis >>> >> >> >> Neither are aliases signatures but they can still be imported. If the >> library writer choose to expose argument names in the .di file then I'd say >> they are part of the API. >> > > The library writer has no choice. > Templates function implementation must be included in the .di file. This > exposes the parameter names. > > The proposal introduces additional coupling between library code and user > code, which is useless in the majority of cases. > > I can see the value in an opt-in annotation (*not* opt-out) for those > problem domains where large numbers of function parameters are normal. But I > would strongly oppose it in general. > >
Re: Pretty please: Named arguments
On Wed, Mar 2, 2011 at 8:45 AM, Jim wrote: > > In addition to that, named template arguments would allow you to create > very customizable, yet lean types. It would be possible to parameterize all > components. Basically, if you're not pleased with the default search > algorithm or container type of a more complex object then you can specify > your own. > Interesting, I hadn't considered the benefits of template arguments with names as far as leanness of types. The best part of naming arguments for functions and methods, in my experience, is that if you add additional arguments to a method, it is a cheap change. I don't have to go and find and change all the client calls that have already been written. I can leave all of the existing source with client code untouched, and only specify the new parameter in the new invocation that wants to use the new functionality. I only have to recompile. Low maintenance. Nice.
Re: How fast is D compared to C++?
> What pisses me off is the Issac Guy doesn't want to support D in the great > language benchmark. It's very important utlity for developers. Most coders > with C and C++ mentality look the charts and only use the top-2 languages, > that is C and C++. If D was there, we could get more users right now, > because the optimization benefits make DMD the fastest. Probably even > hundreds of enterprises go there to see what language to use. Everyone knows > TIOBE is a joke, but this benchmark is probably the most important language > benchmark in the web. D is not listed :-( > > I've been donating few hundred bucks annually to wikipedia, but the > deletionist news force me to rethink this. I could donate them to Issac if > he just supported our language. Must not be that hard? > The benchmarks are public so they can be reproduced, right? That's the standard for scientific publication. I can help you reproduce them and put up a webpage if you want to. But I would suggest that it's only really relevant to benchmark against C and C++. The rest is just eye candy. - Jason
Re: Google Summer of Code
> > maybe QtCreator (http://qt.nokia.com/products/developer-tools/) > (is it LGPL?) can be used as a fork base - so the ide will be > multi-platform at start > I second the idea of Qt based stuff. Yes, Qt *is now* LGPL. Just a recent release. How awesome is that!?! My other suggestion for GSOC projects is three words: or, actually, three characters: ZeroMQ. That would have *much* broader reach than dbus, if not allow easy tunnelling of dbus between hosts (sweet). Jason On Thu, Mar 3, 2011 at 6:25 PM, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > On 3/3/11 6:10 PM, jasonw wrote: > >> Andrei Alexandrescu Wrote: >> >> On 3/3/11 3:48 AM, Jens Mueller wrote: >>> >>>> Dear list, >>>> >>>> Trass3r brought it up and I think it's a very good idea. D is lacking >>>> some man power. The mentoring deadline is 11th of March. There are >>>> important and interesting projects students may work on. >>>> >>>> I'm writing this post seeking answers to >>>> 1. What's the "official" D stand on this matter? >>>> 2. Are there already students who have time and would like to join? What >>>> are you interested in? >>>> >>>> The first question is currently the more important one. The organization >>>> administrator has to submit an application until the above deadline. >>>> The purpose of the second question is to get some feedback whether it >>>> would be worthwhile to submit an application. Because later on students >>>> need to propose/join a project. >>>> >>>> Jens >>>> >>>> PS >>>> The FAQs on http://code.google.com/soc/ is very helpful. >>>> >>> >>> Thanks for this idea. I plan to submit an organization application. As >>> of now I'm unclear whether Digital Mars would be the best organization >>> to apply, as opposed to an unincorporated "d-programming-language.org" >>> entity. I'll discuss this with Walter. All, please chime in if you have >>> related experience. >>> >>> We have a number of good projects to work on: >>> >>> * XML library >>> >>> * Networking library >>> >>> * IDE >>> >>> * Lexer/parser generator >>> >>> * Containers >>> >>> * Encryption/hashing >>> >>> * Thrift bindings >>> >> >> What is Thrift? I read it's a Facebook technology which would benefit >> your career, not D especially. >> > > (Not speaking on behalf of Facebook.) That's not reading, it's reading plus > speculating. Also, there are two mistakes. One, Thrift is an open source > technology used outside Facebook. Second, with me on board, Facebook is > possibly more likely than other influential companies to try out D. If > Facebook does start using D systematically (and availability of Thrift > bindings is an essential ingredient), then a lot of companies will take > notice. > > > Not trying to be political, but as we >> know Facebook and Google are competing enemies. Why do you think >> Google would support some Facebook project financially? >> > > I don't think they'd put things that way, but then I don't know. > > > Why not write D-Bus bindings? D-Bus is the de facto protocol on all >> modern open source operating systems. About as important as COM or >> CLR. COM is supported by D. Why not D-Bus? D-Bus is politically >> neutral technology. >> > > As long as we're just enumerating possible projects, sure. > > > Andrei > -- Jason E. Aten, Ph.D.
Re: LLVM 3.0 type system changes
On Mon, Mar 7, 2011 at 2:03 PM, filgood wrote: > Btw, what is the status of the D2 LLVM compiler? > Here are my impressions. I might title this short collection of thoughts, "LDC2 - one user's early experience." With alot of caveats, my experience as a user of D2 LLVM (which has been only over the last week) has been good. This is very subjective, and not very scientific, but my two cents are: LDC2 is in impressive shape. But I'm new to D as well, so I'm not a very good judge of these things. And here are the caveats: I personally have written only 8-line toy programs with it. LDC2, as far as I know, only does linux. But it does do linux64 (and I assume 32, but I've only tried 64). It doesn't do anything else as far as I know. I tried OSX and there's a bunch things that need careful attention before that version will fly. There's not very good documentation on building LDC2, and figuring out how to build involved getting help on the chat group. But they are very helpful. When I asked Alexey about the gc issues he had mentioned (on a wiki...maybe, I don't recall exactly), he wrote back and said that those issues were now fixed. Many of the optimization levels don't function, but those should be trivial to fix. The build instructions are pretty out of date and the makefiles aren't really configured right, but after mucking with it for a bit, I got it to build. If you can get it to build, it compiles druntime and phobos. That is fairly impressive. It showed good (not 100%, but good) conformance when compared with the dmd2 output on a 100 test subset of the runnable category of tests from https://github.com/D-Programming-Language/dmd. I don't know how comprehensive that test suite is, but it reassured me enough to continue to work with the compiler. Alexey Prokhin--as the current lead developer--deserves applause, loud applause, for his work on LDC2. Thank you Alexey! This is very nice work. - Jason
Re: LLVM 3.0 type system changes
On Tue, Mar 8, 2011 at 2:15 AM, Jens Mueller wrote,
on the old thread titled "LLVM 3.0 type system changes"
> Can you talk me through the building process? I tried it a week ago but
> with no success. Can you post the necessary steps on this list or to me
> in private?
>
I can try to sketch the important aspects, but obviously this protocol
hasn't been tested very widely, so feel free to post back any refinements.
Even better if you want to patch the repositories. Some of these may be out
of order, especially the CMakeCache.txt edits, so if anything goes wrong,
check the variables mentioned below in CMakeCache.txt, and that your
ldc2.conf is correct. Those are the most important two control files.
I'll start a new thread with a new title to make this easy to find, and more
on topic.
I. Acknowledgements
Heavy credit for this is due to mrmonday on #ldc who guided me and
graciously offered
assistance. Errors and typos are mine alone.
I. Protocol: "Building LDC2 on Linux x86_64, as of Feb 28 2011":
II. Protcol: Building LDC2 on Linux x86_64.
Prereqs: cmake, git, hg, llvm2.8 from source already installed (package
installs of llvm2.8 might work too, I don't know).
# 1) Check out ldc2, druntime, and phobos2:
$ hg clone https://bitbucket.org/prokhin_alexey/ldc2
$ cd ldc2
$ git clone https://github.com/AlexeyProkhin/druntime
$ git clone https://github.com/AlexeyProkhin/phobos
# 2) Configure (apparently you can also use ccmake with gui, but I
didn't)$ cmake .
# 3) Fix up the CMakeCache.txt file:
# 3 a) edit CMakeCache.txt by hand, and set D_VERSION to 2, as on
these two lines:
...
//D language version - will originally be set to 1, change it to 2 like this:
D_VERSION:STRING=2
...
# 3 b) check on the variables mentioned in 3 d). I don't think that
they will be present yet, but
if they aren't, it can't hurt to fix them now as well.
# 3 c) make (this should hopefully build bin/ldc2 now )
$ make
# there will be some const warnings, but the build finishes for me.
# 3 d) edit CMakeCache.txt again (it will have changed/had appendixes
now I think) and fix these two variables:
...
//runtime source dir
RUNTIME_DIR:PATH=/home/jaten/pkg/ldc2/ldc2/druntime
...
//phobos2 source dir
PHOBOS2_DIR:PATH=/home/jaten/pkg/ldc2/ldc2/phobos
...
# 4) modify your your .bashrc to set PATH to include ./bin in front of
everything else
echo "export PATH=`pwd`/bin:\$PATH" >> ~/.bashrc
. ~/.bashrc
which ldc2 # should show the one in ./bin now
# 5) build druntime and phobos with the command: make phobos2
$ make phobos2
# 6) edit ./bin/ldc2.conf so that it points to the right places. Here is
a copy of mine that seems to work. The point of the editing is to make sure
that paths are correct, especially the third -I (Include line), which was
often wrong out of the box when I was working with it.
jaten@dfw:~$ cat ldc2.conf
// This configuration file uses libconfig.
// See http://www.hyperrealm.com/libconfig/ for syntax details.
// The default group is required
default:
{
// 'switches' holds array of string that are appends to the command line
// arguments before they are parsed.
switches = [
"-I/home/jaten/pkg/llvm+lldb+ldc/prokhin_alexeys_ldc2/ldc2/druntime/import",
"-I/home/jaten/pkg/llvm+lldb+ldc/prokhin_alexeys_ldc2/ldc2/druntime/src",
"-I/home/jaten/pkg/llvm+lldb+ldc/prokhin_alexeys_ldc2/ldc2/phobos/",
"-L-L/home/jaten/pkg/llvm+lldb+ldc/prokhin_alexeys_ldc2/ldc2/runtime/../lib",
"-defaultlib=phobos2",
"-debuglib=phobos2"
];
};
jaten@dfw:~$
# 7) Finished. Test and note variances from the protocol above.
III. Appendix: Trouble shooting notes
If anything goes wrong, in my experience it was due to the settings in
either CMakeCache.txt, or in ./bin/ldc2.conf Those are the two places I
would look at first when troubleshooting.
A) When you edit the CMakeCache.txt, be sure to check that PHOBOS2_DIR gets
set to ./phobos and not ../druntime
# example that works:
jaten@dfw:~$ cat CMakeCache.txt.afarm_works_ldc2 | grep PHOBOS2_DIR
PHOBOS2_DIR:PATH=/home/jaten/pkg/llvm+lldb+ldc/prokhin_alexeys_ldc2/ldc2/phobos
# example that DOES NOT work:
jaten@dfw:~$ cat CMakeCache.txt.dfw_notwork_ldc2 | grep PHOBOS2_DIR
PHOBOS2_DIR:PATH=/home/jaten/pkg/ldc2/ldc2/../druntime
B) Be sure in CMakeCache.txt you have these three variables set correctly,
with obvious edits for your paths, not mine:
...
//D language version
D_VERSION:STRING=2
...
//runtime source dir
RUNTIME_DIR:PATH=/home/jaten/pkg/ldc2/ldc2/druntime
...
//phobos2 source dir
PHOBOS2_DIR:PATH=/home/jaten/pkg/ldc2/ldc2/phobos
how to build LDC2 on linux x86_64
Let's add any comments to this protocol on this, it's own thread, rather
than on the old thread, to encapsulate and localize -- so as to make it
easier to find and replicate installion.
Thanks.
- Jason
On Tue, Mar 8, 2011 at 2:15 AM, Jens Mueller wrote,
on the old thread titled "LLVM 3.0 type system changes"
> Can you talk me through the building process? I tried it a week ago but
> with no success. Can you post the necessary steps on this list or to me
> in private?
>
I can try to sketch the important aspects, but obviously this protocol
hasn't been tested very widely, so feel free to post back any refinements.
Even better if you want to patch the repositories. Some of these may be out
of order, especially the CMakeCache.txt edits, so if anything goes wrong,
check the variables mentioned below in CMakeCache.txt, and that your
ldc2.conf is correct. Those are the most important two control files.
I'll start a new thread with a new title to make this easy to find, and more
on topic.
I. Acknowledgements
Heavy credit for this is due to mrmonday on #ldc who guided me and
graciously offered assistance. Errors and typos are mine alone.
II. Protocol: Building LDC2 on Linux x86_64
Version: 07 March 2011
Prereqs: cmake, git, hg, llvm2.8 from source already installed (package
installs of llvm2.8 might work too, I don't know).
# 1) Check out ldc2, druntime, and phobos2:
$ hg clone https://bitbucket.org/prokhin_alexey/ldc2
$ cd ldc2
$ git clone https://github.com/AlexeyProkhin/druntime
$ git clone https://github.com/AlexeyProkhin/phobos
# 2) Configure (apparently you can also use ccmake with gui, but I
didn't)$ cmake .
# 3) Fix up the CMakeCache.txt file:
# 3 a) edit CMakeCache.txt by hand, and set D_VERSION to 2, as on
these two lines:
...
//D language version - will originally be set to 1, change it to 2 like this:
D_VERSION:STRING=2
...
# 3 b) check on the variables mentioned in 3 d). I don't think that
they will be present yet, but
if they aren't, it can't hurt to fix them now as well.
# 3 c) make (this should hopefully build bin/ldc2 now )
$ make
# there will be some const warnings, but the build finishes for me.
# 3 d) edit CMakeCache.txt again (it will have changed/had appendixes
now I think) and fix these two variables:
...
//runtime source dir
RUNTIME_DIR:PATH=/home/jaten/pkg/ldc2/ldc2/druntime
...
//phobos2 source dir
PHOBOS2_DIR:PATH=/home/jaten/pkg/ldc2/ldc2/phobos
...
# 4) modify your your .bashrc to set PATH to include ./bin in front of
everything else
echo "export PATH=`pwd`/bin:\$PATH" >> ~/.bashrc
. ~/.bashrc
which ldc2 # should show the one in ./bin now
# 5) build druntime and phobos with the command: make phobos2
$ make phobos2
# 6) edit ./bin/ldc2.conf so that it points to the right places. Here is
a copy of mine that seems to work. The point of the editing is to make sure
that paths are correct, especially the third -I (Include line), which was
often wrong out of the box when I was working with it.
jaten@dfw:~$ cat ldc2.conf
// This configuration file uses libconfig.
// See http://www.hyperrealm.com/libconfig/ for syntax details.
// The default group is required
default:
{
// 'switches' holds array of string that are appends to the command line
// arguments before they are parsed.
switches = [
"-I/home/jaten/pkg/llvm+lldb+ldc/prokhin_alexeys_ldc2/ldc2/druntime/import",
"-I/home/jaten/pkg/llvm+lldb+ldc/prokhin_alexeys_ldc2/ldc2/druntime/src",
"-I/home/jaten/pkg/llvm+lldb+ldc/prokhin_alexeys_ldc2/ldc2/phobos/",
"-L-L/home/jaten/pkg/llvm+lldb+ldc/prokhin_alexeys_ldc2/ldc2/runtime/../lib",
"-defaultlib=phobos2",
"-debuglib=phobos2"
];
};
jaten@dfw:~$
# 7) Finished. Test and note variances from the protocol above.
III. Appendix: Troubleshooting notes
If anything goes wrong, in my experience it was due to the settings in
either CMakeCache.txt, or in ./bin/ldc2.conf Those are the two places I
would look at first when troubleshooting.
A) When you edit the CMakeCache.txt, be sure to check that PHOBOS2_DIR gets
set to ./phobos and not ../druntime
# example that works:
jaten@dfw:~$ cat CMakeCache.txt.afarm_works_ldc2 | grep PHOBOS2_DIR
PHOBOS2_DIR:PATH=/home/jaten/pkg/llvm+lldb+ldc/prokhin_alexeys_ldc2/ldc2/phobos
# example that DOES NOT work:
jaten@dfw:~$ cat CMakeCache.txt.dfw_notwork_ldc2 | grep PHOBOS2_DIR
PHOBOS2_DIR:PATH=/home/jaten/pkg/ldc2/ldc2/../druntime
B) Be sure in CMakeCache.txt you have these three variables set correctly,
with obvious edits for your paths, not mine:
...
//D language version
D_VERSION:STRING=2
...
//runtime source dir
RUNTIME_DIR:PATH=/home/jaten/pkg/ldc2/ldc2/druntime
...
//phobos2 source dir
PHOBOS2_DIR:PATH=/home/jaten/pkg/ldc2/ldc2/phobos
Good luck!
Re: how to build LDC2 on linux x86_64
On Tue, Mar 8, 2011 at 8:05 AM, Jason E. Aten wrote: -> NB, first refinement: I think steps 5 & 6 might be out of order above.
Re: LLVM 3.0 type system changes
On Tue, Mar 8, 2011 at 7:58 AM, Jason E. Aten wrote: > I. Protocol: "Building LDC2 on Linux x86_64": > Please see the new thread titled, "how to build LDC2 on linux x86_64". There is already one correction posted there already. My apologies: I didn't mean to replicate this in both threads. A typo keypress posted it here before it was ready. Please make any refinements on how to install LDC2 on that thread. Thanks! Jason
Re: Is DMD 2.052 32-bit?
On Wed, Mar 9, 2011 at 12:55 AM, Walter Bright wrote: > On 3/8/2011 1:23 PM, Trass3r wrote: > >> Yes, but you can compile an x64 dmd yourself on Linux. >>> >>> Is there any "how to"? >>> >> >> IIRC you have to edit linux.mak to use -m64 instead of -m32. >> > > It has worked in the past, but the 64 bit build is not regularly tested. > When I tried this last week, changing -m32 to -m64 got me a clean 64-bit build of dmd2, with no build errors. Very easy. A caveat-- I tried the same search and replace s/32/64/ in places on the druntime and phobos makefiles, but there was something more subtle going on--the generated libraries built fine but were still 32-bit objects inside the .a archives. Somehow I wasn't passing the right flags to generate 64-bit libraries. Is there a flag to tell dmd to compile to 64-bit objects? Thanks, Jason
Re: Is DMD 2.052 32-bit?
An alternative: I would point out that LDC2 is 64-bit and open source. It lets you target a multitude of architectures, including, recently, OpenCL for GPGPU. Heck, you might even be able to cross compile from Linux and target your system of choice. So if you really want 64-bit support for platform X, you could likely add it to LDC2 without too much work. Jason -- Jason E. Aten, Ph.D.
Re: Different types with auto
> auto x1=1., x2=2., x3=3., x4=4., x5=5, x6=6.; If the coder wanted them to all be doubles, it's easy to require that by just saying so, and then even x5 will be a double. double x1=1., x2=2, ... So it seems to me that auto does exactly what you asked it to here, and I actually prefer this behavior for conciseness and expressiveness sake.
Re: Library Development: What to finish/flesh out?
On Thu, 17 Mar 2011 15:33:10 +, dsimcha wrote: > 5. Matrix operations: SciD improvements that allow you to write matrix > operations that look like normal math/MATLAB and optimizes them via > expression templates so that a minimal number of temporary matrices are > created. Uses/will use BLAS for multiplication. Completion state: > Addition implemented. Multiplication not. Nice matrix ops get my vote for what I would find most useful. Having matrices with m.rownames and m.colnames (similar to R's rownames(m) and colnames(m) for a matrix m), would be great too.
a cabal for D ?
Please correct me if I'm wrong, but I observe that there doesn't appear
to be a package management system / standard repository for D libraries.
Or is there?
I'm talking about something as easy to use as R's CRAN,
> install.packages("rforest")
or cpan for perl, ctan for latex, dpgk/apt for debian, cabal for Haskell/
Hackage, etc.
If there's not a commonly utilized one currently, perhaps we could
"borrow" cabal, with a trivial port. cabal is Haskell's package manager.
Not only does having a standard package install system facilitate
adoption, it greatly facilitates code sharing and library maturation.
Re: Dream package management system (Was: a cabal for D ?)
>> On 3/17/11 4:00 PM, Tomek Sowiński wrote: >> Yes, we need it badly. >> I think it's a good moment to start a discussion. First off, what >> exactly do we want from a package management system? > On Thu, 17 Mar 2011 16:28:37 -0500, Andrei Alexandrescu wrote: > Yah, would be great. It would be awesome if an expert in e.g. apt would > join D and create the design of a package management system. I would invite interested parties to review the cabal/cabal-install/ Hackage system documentation. It is described here. http://www.haskell.org/haskellwiki/How_to_write_a_Haskell_program Haskell has over 2000 contributed user libraries--largely because they have such a nice, easy to use, and well documented package system. Rather than expend much effort, in the tradition of lazy evaluation and getting 80/20 the way there, I would prefer to just do a clone of an already successful system such as cabal (or ?) and then take feedback to based on actual usage with D. Thoughts? Comments welcome. Jason
Re: Dream package management system (Was: a cabal for D ?)
Somewhat tongue in cheek, we could call it dabal. As in, "get on dabal!" :-)
Re: a cabal for D ?
On Fri, 18 Mar 2011 18:42:36 +, Russel Winder wrote: > I still think basing a D packaging system on Git to be the best > direction. Basing package distribution on Git or hg could be a big win, and would help establish a customary case for revision control which is one of the things that make cabal work so well (they use darcs for everything). I find these revision control systems ver fast and very easy to use. The other thing that cabal standardizes is the make/build system. I've updated bud/build to compile under D2, with all the latest patches, but I'm far from convinced that it should be a make system of choice. I have limited experience here, but a "D aware" build system would seem to be highly preferable. What are people's experiences with the various options for build systems with D? To me, I like the design goals of Andreas Fredriksson's Tundra build system (he wants speed of incremental of builds prioritized over all else, which means utilizing multicores for builds as much as possible to get the quickest build), because fast builds are critical for game development, where D is very attractive. Game projects compile tens of thousands of files. Tundra is GPL and it would be easy to extend to support D. http://voodoo-slide.blogspot.com/2010/08/tundra-my-build-system.html https://github.com/deplinenoise/tundra https://github.com/deplinenoise/tundra/downloads
incremental builds for D projects... challenging or close at hand?
> On Sat, 19 Mar 2011 12:19:58 +0100, Jacob Carlborg wrote: >> What are people's experiences with the various options for build >> systems with D? > > It's not very easy to make an incremental build system for D because of > several reasons. Some are due to how the language works and some are due > to how DMD works: > > * DMD doesn't output all data in all the object files - This can perhaps > be solved by compiling with the -lib switch > > * When you change one D file you need to recompile ALL files that depend > on the changed file. To compare with C/C++ which has source and header > files you only need to recompile the source file if you change it > > * DMD doesn't keep the fully qualified module name when naming object > files resulting in foo.bar will conflict with bar.bar. Issue 3541. [The above is from the packaging system discussion in the "a cabal for D?" thread; here I am branching this to a new topic because I'd like anyone interested in incremental build processes to notice and contribute if they have input.] That is an interesting observation, Jacob. Thank you for pointing that out. Is there anything else (open question anyone) that would prevent D projects from doing incremental builds? Lack of support for incremental builds is a show stopper. Or in this case, the show would never get funded to begin with. Or to ask it another way, what would it take to get incremental builds?
new dr. dobbs article by Walter
Dr. Dobb's Journal just published a blog entry by Walter that discusses some of the motivation and design for the std/conv.d library. As a relative newcomer to D, I found it quite an interesting read. User Defined Literals in the D Programming Language 06 April 2011 http://drdobbs.com/blogs/tools/229401068
