Re: DConf 2013 keynote
Thank you, nicely explained.
Re: DConf 2013 keynote
Ah, makes sense, sorry for the misunderstanding.
Re: DConf 2013 keynote
In any case, I totally agree that if a language *needs* an IDE in order to cope with the amount of required boilerplate, then something is clearly very, very wrong at a fundamental level. May be this is true for expert or professional programmers. But for people like me who only use D occasionally an IDE is a must. IDE mainly helps me in reducing the amount of things I need to memorize or remember like API, building tool names, command syntaxes, etc. This is very important as my main profession is not programming. I think lack of IDEs will prevent many beginners from trying out a new language. Especially after getting spoiled with IDEs like netbeans, visual studio etc. Currently using DIDE, not perfect but better than nothing. VisualD seems to have good reviews but I cannot install it as it requires admin privileges. All the above will still be true even for a "perfect" programming language.
Re: DConf 2013 last talk
My journey using GUI libs is as follows: 1. Started using DWT lib (old one, when it was still supported) 2. DWT was abandoned, so I moved to DFL, tinkered with min-win etc 3. DFL is abondened now? ... moved to GTKD 4. GTKD is good, but API is hard to understand (atleast for me) 5. DWT is supported again, so move back to DWT 6. ???
Re: DConf 2013 last talk
Any plans or roadmap on including a GUI lib in phobos? Is it 5 years away? 10 years? Never?
Re: Support of dmd2 in Waf
On Mon, Oct 10, 2011 at 7:09 PM, Russel Winder wrote: > Not sure about CMake, I have tried is with D. > CMake for D2 limps along. At last check, it passed regression with 2.054 but may need some TLC for 2.055. http://code.google.com/p/cmaked2/wiki/GettingStarted
fiber local storage
Not available yet, but Intel announced support for manipulating FS and GS in user mode. Protection for fiber local storage is one use case. http://software.intel.com/file/36945
Re: Discuss here the best article iPad2 contest
My favorite was Schveighoffer's (had to look carefully to spell that) on D slices. I liked the balance of code and text, low abuse of 'be' verbs and pronouns -- and I learned!
Re: Vote here for best article iPad2 contest
[4] D Slices by Steve Schveighoffer
Re: Marketing D [ was Re: GCC 4.6 ]
On Sun, Oct 31, 2010 at 9:43 PM, SK wrote: > On Sun, Oct 31, 2010 at 9:19 PM, Andrei Alexandrescu > wrote: >> No Windows? > > My Google-fu shows most complaints related to LLVM on Windows are > actually clang problems. I also came across this, but maybe old news > here: > http://software.intel.com/en-us/blogs/2009/05/27/why-we-chose-llvm/ > On further reading, it seems that the reason LLVM is not the focus is answered in the previous thread about gcc 4.6. To paraphrase, the answer is not just lackluster Windows support, but also that Walter has a professional and business interest in advancing back-end compiler technology. Fair enough.
Re: Marketing D [ was Re: GCC 4.6 ]
On Sun, Oct 31, 2010 at 9:19 PM, Andrei Alexandrescu wrote: > No Windows? My Google-fu shows most complaints related to LLVM on Windows are actually clang problems. I also came across this, but maybe old news here: http://software.intel.com/en-us/blogs/2009/05/27/why-we-chose-llvm/
Re: Marketing D [ was Re: GCC 4.6 ]
On Sun, Oct 31, 2010 at 6:29 PM, Walter Bright wrote: > I don't agree. There's very little, almost no, D specific support in the dmd > back end. It's a C compiler back end. Nearly all the work is done in the > front end, which should be little more than a cut & paste job for LDC and > GDC once they are already up and running with the front end. As a casual observer of D, I've wondered in the past: why isn't D2 and the D community in general already using LLVM's backend by default? Seems that compiler back-ends are full of nitty-gritty details and relatively unglamorous work. This post makes me think there is nothing in the way, so why not just rally around LLVM and spend the time savings on more D-centric issues?
Re: [nomenclature] systems language
On Sat, Oct 16, 2010 at 1:36 AM, Paulo Pinto wrote: > Maybe you should improve your english skills. I was being sarcastic. > I ran a diagnostic on my English and guess what? It's just fine! What's not fine is the way Gmail displays threads. At least in my configuration, it looked like you were responding to my post. So now I'm a more enlightened Gmailer.
Re: [nomenclature] systems language
On Thu, Oct 14, 2010 at 11:39 PM, Paulo Pinto wrote: > You just ruled out C as a systems language. > No, C is a systems language and fits my definition. 1) C need not overlay software written in another language 2) C allows expression of essential machine independent concepts How did inline assembly become a requirement? For machine dependent code, I can just link C with assembly. But it's still easy to nitpick against C. For example, ANSI C cannot express the family of atomic operations, which one could argue are essential machine independent concepts.
Re: [nomenclature] systems language
On Thu, Oct 14, 2010 at 5:30 AM, Justin Johansson wrote: > Touted often around here is the term "systems language". > > May we please discuss a definition to be agreed upon > for the usage this term (at least in this community) and > also have some agreed upon examples of PLs that might also > be members of the "set of systems languages". A fun question without a precise answer -- like the "i know it when I see it" definition of obscenity. IMO, a systems language has two key characteristics: 1) A systems language expresses software that does not overlay software written in another language. "Overlay" includes running over interpreters and/or kernels. 2) A systems language allows machine independent concepts to be expressed in the language. This means I can't call my flimsy language a systems language by falling back on assembly to fill conceptual gaps that recur on every platform. It also rules out assembly itself as a systems language. When a concept is machine dependent, e.g. "read the x86 time stamp counter register", then assembly is perfectly permissible. Some on this list have opined that D is not aiming at operating system software, so maybe D is an "aspiring" systems language for the time being. Regards, -steve
Re: CMake for D2 ready for testers
On Fri, Oct 8, 2010 at 12:41 PM, Jens Mueller wrote: > I also think CMake isn't that shiny. But you can get the job done once > you're familiar with it. My sentiments exactly. Discussing the beauties of a particular build system is all well and good, but what really matters are the warts that emerge only after you're a long way into a big project.
Re: CMake for D2 ready for testers
On Mon, Sep 6, 2010 at 1:53 AM, Nick Sabalausky wrote: > "Jonathan M Davis" wrote in message > news:mailman.114.1283754439.858.digitalmar...@puremagic.com... >> On Sunday 05 September 2010 22:55:58 Nick Sabalausky wrote: >>> >>> Not to be contentious, just curious about the design philosophy behind >>> cmake: Why is it a layer on-top of make at all instead of just bypassing >>> the antiquated make altogether? GNU autotools does the same thing (ie, >>> "fix" make by just adding more layers on top of it), and that always >>> struck me as silly. Is there some particular reason for this approach? >> >> cmake can generate a variety of different build system files, including >> both >> makefiles and visual studio project files. So, you can use the same cmake >> files to >> generate build stuff for multiple OSes. Also, it's a lot cleaner and >> simpler to >> set a lot of stuff up then it is in makefiles. When KDE was using >> autotools, they >> pretty much couldn't do a Windows version because it would have been too >> disgusting to alter them as necessary. However, after having switched to >> cmake, >> they could do it. I haven't used it a whole lot at this point, so I'm not >> sure >> of all of the ins and outs, but it's a lot more pleasant to deal with than >> makefiles, and it's a lot more flexible. >> > > Well, I guess what I mean is, compared to something like SCons, Rake or > A-A-P. Those tools, like cmake, handle cross-platform no problem while > providing far saner syntax than traditional make. But unline cmake, they > don't have any reliance on traditional make even on unix. Granted, they > don't generate IDE project files, but my initial impression of that is > importing information *from* IDE project files would seem to be a more > practical approach. > > From what tiny bit I read on the site (it seemed suprisingly hard to find > the documentation on the site, but maybe that was just me), it does seem > heavily C/C++ centric, and so it looks like it may be able to handle > different C/C++ compilers fairly well. By contrast, SCons and Rake, as far > as I can tell, don't seem to have any specific provisions for abstracting > different compilers for a single language (though A-A-P does try to do > that). So maybe that has something to do with it? > > Again, I hope I'm not coming across as challenging the usefulness or quality > of cmake - that's not my intent. Just curious about why it chooses not to > ditch traditional-make entierly like some of the other build systems do. > Hi Nick - Yes, it's certainly a debatable question but I can't offer special insight. Skipping my own long and checkered experiences with build systems, I'll say that CMake has been the first to reach the lofty level of "satisfactory". Some related reading: Why KDE switched to cmake: http://lwn.net/Articles/188693 The CMake documentation is OK. 90% of the time I look here: http://www.cmake.org/cmake/help/cmake-2-8-docs.html The command line --help is extensive. Regards, -steve
CMake for D2 ready for testers
Why labor over buggy Makefiles when you could be laboring over buggy CMake files at a much more productive level of abstraction? :o) With excellent help from Jens Mueller and Dean Calver, CMake for D2 now passes our small suite of unit tests on both Windows and Linux. Our tests include mixed C-D applications and libraries. We tested with CMake 2.8.2 and DMD 2.048. We'd appreciate if a few hardy souls were willing to take a test drive. Check it out here: http://code.google.com/p/cmaked2. Please report problems on the cmaked2 tracker rather than here. Unfortunately, we have not had an opportunity to test on Mac OS's. Briefly, CMake is a cross-platform "make maker". Many people find CMake more attractive than traditional Makefiles or Autotools, especially for large projects. You can find more information here: http://www.cmake.org. Cheers, -steve
Re: On C/C++ undefined behaviours
2010/8/21 Tomek Sowiński : > Interesting. Hypothesising, wouldn't it be better if compiling to metal > happened already during installation? Nice idea for hand-helds for sure. In a big computing environments, the situation is trickier. For example, a network storage device may contain the intermediate code installation used by many and varied client machines. Each client may load and finish compilation differently over fast local networks. Your idea might still be a meaningful head start to the process even in that case.
Re: On C/C++ undefined behaviours
On Fri, Aug 20, 2010 at 11:38 PM, Walter Bright wrote: > SK wrote: >> >> On Fri, Aug 20, 2010 at 10:11 PM, Walter Bright >> wrote: >>> >>> SK wrote: >>>> >>>> Do you mean to say: >>>> Instead of shipping the intermediate code, always ship source code. >>> >>> Yes. >>> Why doesn't it make sense? >> >> I love open source projects, but off the top of my head here are some >> reasons that's not a general substitute for TIMI for D: >> 1) What about closed source software? > > Won't work anyway. Java bytecodes are trivially turned back into source. IMO, reverse engineering technology is not the issue. > >> 2) From-source builds may be more complex or resource consuming than >> could be accommodated on the machine the customer used to launch, e.g. >> a hand-held device. > > I've worked on a Java VM enough to know that won't be a problem. > Why waste your batteries running deep and complex front-end optimizers that have nothing to do with the target platform? >> 3) The source may have sizable irrelevant content for a particular >> product instantiation, compile time conditionals, etc > > You can run it through a comment stripper first. Why stop there? If you have to create some waypoint that isn't really the source and isn't the binary, why not finish off the platform independent lifting in the front end? I am getting zero admission from you that there is any goodness to be found in the TIMI thing. I don't understand that. Do you really just hate the idea through and through?
Re: On C/C++ undefined behaviours
Hi Nick, On Fri, Aug 20, 2010 at 10:37 PM, Nick Sabalausky wrote: > > I'm curious what you have to say about #1. But I consider #2 to be a very > poor reason because: > > - There's always reverse engineering. > - There's always obfuscation. > - IL may even provide better reverse-engineering results than machine code, > depending on the IL. > - All the companies sinking time and money into JS and PHP middleware don't > seem to have a problem with handing out their source. > - If someone's gonna steal a product and rebrand it as their own, they don't > usually need the source, and having it would probably only be of fairly > small help, if any. > - As a customer, the idea of spending money on a product that I can't > service myself if/when the company goes under or loses interest makes me > nervous. Providing their source would given them a competetive advantage. > - Even though providing source gets in the way of effective DRM (as if there > even were such a thing), DRM itself gets in the way of sales. > - Distributing in source form makes certain things possible that wouldn't > otherwise be, like virtual template functions (in theory, even if not in > actual D practice). > Yes, yes and yes - especially about not needing source to be a pirate. But your perspective is not shared by many big companies shipping software I care about. The open source movement has even turned up the contrast in this regard for closed source companies. Without conducting a thorough Fortune 500 survey, I will assert that shipping source is an emotionally burdened action at the management level, and this roadblock is avoided by "simply" running code through front end compilation. So, just do that and move on the to next problem.
Re: On C/C++ undefined behaviours
On Fri, Aug 20, 2010 at 10:11 PM, Walter Bright wrote: > SK wrote: >> >> Do you mean to say: >> Instead of shipping the intermediate code, always ship source code. > > Yes. > Why doesn't it make sense? I love open source projects, but off the top of my head here are some reasons that's not a general substitute for TIMI for D: 1) What about closed source software? 2) From-source builds may be more complex or resource consuming than could be accommodated on the machine the customer used to launch, e.g. a hand-held device. 3) The source may have sizable irrelevant content for a particular product instantiation, compile time conditionals, etc I have no vested interest in the TIMI idea, but it feels good to me. We get platform independence, custom fit binaries, and require no change to the language. Not to mention it's proven to be a durable model at IBM.
Re: On C/C++ undefined behaviours
On Fri, Aug 20, 2010 at 8:46 PM, Walter Bright wrote: > SK wrote: >> >> Then to make this more concrete, what if D had an option to suspend >> compilation after the front-end finished? The resulting executable >> contains the abstract RTL blobs and the compiler backend, which >> finishes the job for the specific platform on which the executable is >> launched. The final binary is cached for subsequent launches. You >> get good machine independence and the approach provides performance >> wins for operations like vectorizing where you don't know in advance >> what kind of SSE support you'll find. >> >> Hypothetically, why not? > > It's an old idea, but I think it's pointless. Instead of caching the > intermediate code, just cache the source code. > > Huh? Do you mean to say: Instead of shipping the intermediate code, always ship source code. -or- Instead of caching the binary, just cache the source code. Neither of those guesses make general sense so I'm afraid I miss your point.
Re: On C/C++ undefined behaviours
On Fri, Aug 20, 2010 at 7:07 PM, Walter Bright wrote: > SK wrote: >> >> On Fri, Aug 20, 2010 at 4:16 PM, Walter Bright >> wrote: >>> >>> And frankly, it's retarded to compile the same program over and over, >>> every >>> time you use it. >> >> How about IBM's TIMI? My understanding is that it's a hybrid approach >> that gives you machine independence with a one-time recompilation that >> is stored back into the executable. Or something like that. > > Beats me, I've never heard of it. > Then to make this more concrete, what if D had an option to suspend compilation after the front-end finished? The resulting executable contains the abstract RTL blobs and the compiler backend, which finishes the job for the specific platform on which the executable is launched. The final binary is cached for subsequent launches. You get good machine independence and the approach provides performance wins for operations like vectorizing where you don't know in advance what kind of SSE support you'll find. Hypothetically, why not? I dug around and found this: http://www.itjungle.com/tfh/tfh082007-printer01.html >From the article. Without getting too technical, here's what happens on the OS/400 and i5/OS platform when you create applications, which explains the problem customers ran into in 1995 and which IBM wants them to avoid in 2008. A programmer writes an application in say, RPG. They run it through a compiler, either using the Original Program Model (OPM) or the Integrated Language Environment (ILE) compilers, and the code compiles so they can run it. Or, rather, that is what it looks like to the programmer. What is really happening is that this application is compiled into an intermediate stage, which some IBMers have called RPG templates (in the case of RPG applications). These templates have a property called observability, which in essence means they are compiled to the TIMI layer. These intermediate templates are then used by the TIMI layer on an actual piece of hardware with a specific processor and instruction set to compile the application to run on that specific processor. TIMI compiles these RPG templates down to actual compiled code behind the scenes the first time an application runs, and because the code was originally compiled to the TIMI layer, there is no need to change the source code. Only the object code changes, which end users never had access to anyway because only TIMI can reach down there. This is the brilliant way that IBM has preserved customers' vast investments in RPG, COBOL, and other applications over the years
Re: On C/C++ undefined behaviours
On Fri, Aug 20, 2010 at 4:16 PM, Walter Bright wrote: > And frankly, it's retarded to compile the same program over and over, every > time you use it. How about IBM's TIMI? My understanding is that it's a hybrid approach that gives you machine independence with a one-time recompilation that is stored back into the executable. Or something like that. -steve
Re: inline asm plans
On Mon, Aug 16, 2010 at 7:13 PM, Brad Roberts wrote: > Please file an enhancement bug report (at a minimum). Even better would > be to take a look at the source and produce a patch adding support for it > (iasm.c in the src tree). > > Adding new codes shouldn't be terribly difficult, but I've not studied > that particular part of the code yet. > Hi Brad, I followed your suggestion and looked at iasm.c, but this file has the backend license. Code from random contributors complicates copyright -- a problem made much simpler if the relevant files were also under the Artistic/GPL. Does it makes sense for Digital Mars to "move" the inline assembler to be considered part of the front-end? >From src/iasm.c /* * Copyright (c) 1992-1999 by Symantec * Copyright (c) 1999-2010 by Digital Mars * All Rights Reserved * http://www.digitalmars.com * Written by Mike Cote, John Micco and Walter Bright * D version by Walter Bright * * This source file is made available for personal use * only. The license is in /dmd/src/dmd/backendlicense.txt * For any other uses, please contact Digital Mars. */
Re: inline asm plans
On Sat, Aug 14, 2010 at 2:56 PM, SK wrote: > Will D try to stay current with new processor instructions or provide > just a lowest common denominator? I notice that newer x86 > instructions such as CRC32 and POPCNT are not supported by the inline > assembler. > Well, this one was certainly a dud. ;^) I get the feeling I'm more down on the metal than most folks on this interesting list. Can anyone opine about assembler plans? Some new instructions offer a meaningful performance boost in the right niche, so I hate to think the assembler won't expose them. -steve
OPTLINK & cmake
Under Windows, OPTLINK (8.00.2) gets confused when an object file has a compound extension with than one '.' in the name, as in foo.d.o. For such files, OPTLINK reports "Error 2: File Not Found foo.d". Cmake always generates object files with a compound extension. I'm already asking cmake people, but a work-around may not be forthcoming. What is the right way to get OPTLINK fixed? -steve
inline asm plans
Will D try to stay current with new processor instructions or provide just a lowest common denominator? I notice that newer x86 instructions such as CRC32 and POPCNT are not supported by the inline assembler.
Re: dmd as link driver
On Fri, Aug 13, 2010 at 1:02 AM, Walter Bright wrote: > > dmd does drive the linker. For example: > > Oops, sorry. I was thrown off the trail by the -L-l syntax for including a library. Gnu is my comfort zone and I went there without thinking. $ dmd -w -wi -c main.d $ dmd main.o -lphobos2 Error: unrecognized switch '-lphobos2' $ dmd main.o -L-lphobos2 (success)
dmd as link driver
Hello D'ers, Can dmd drive the linking process in two step compile-then-link builds? Lacking this capability complicates the CMake discovery process that uses small test compiles. In short, the problem is that CMake needs, but does not have, full knowledge of the C environment (to handle linking) before testing the D environment. I'm not a cmake expert, but I don't think I can express this dependency between two tool chains. A few experiments have failed to get this working. If the answer is that dmd cannot drive the linker, would a patch be easy enough to consider? -steve
Re: synchronized vs. C volatile
On Mon, Aug 9, 2010 at 9:55 AM, Lutger wrote:
>
> I'm not an expert on this, but if I am not mistaken the shared type
qualifier
> will handle the barriers, require atomic ops and prevent reordering
compiler
> optimizations so it looks like this one will take care of what volatile
used to
> do, right?
>
>
Seems the latest dmd in svn hasn't implemented shared atomics yet anyway.
If it had, we'd see a lock prefix in use.
$ cat main.d
shared int x = 1;
int main()
{
x = x + 1;
++x;
return 0;
}
$ dmd -O -w -wi main.d
$ objdump -d main.o
main.o: file format elf32-i386
Disassembly of section .text:
<.text>:
0: c3 ret
1: 60 pusha
2: b8 14 00 00 00 mov$0x14,%eax
7: b9 00 00 00 00 mov$0x0,%ecx
c: 8b 11 mov(%ecx),%edx
e: 89 10 mov%edx,(%eax)
10: 89 01 mov%eax,(%ecx)
12: 61 popa
13: c3 ret
Disassembly of section .text._Dmain:
<_Dmain>:
0: 55 push %ebp
1: a1 00 00 00 00 mov0x0,%eax
6: 40 inc%eax
7: a3 00 00 00 00 mov%eax,0x0
c: 8b ec mov%esp,%ebp
e: 31 c0 xor%eax,%eax
10: 83 05 00 00 00 00 01addl $0x1,0x0
17: 5d pop%ebp
18: c3 ret
Re: synchronized vs. C volatile
On Mon, Aug 9, 2010 at 9:55 AM, Lutger wrote: > > I'm not an expert on this, but if I am not mistaken the shared type qualifier > will handle the barriers, require atomic ops and prevent reordering compiler > optimizations so it looks like this one will take care of what volatile used > to > do, right? > > Right, shared sounds better. However, atomics must not sneak in: * Many processors do not support atomics Even with processor support, * Many device interconnects do not support atomic transactions Even with interconnect support, * Many devices do not support atomic transactions and will just generate a bus error So long as code does not attempt a read-modify-write operation, shared has the opportunity to do the right thing, namely implement volatile semantics. Cases with volatile read-modify-write would have to be split -- awkward, but maybe ok? asm() hacks to fake volatile are too embarrassing to consider in a promising new systems language! -steve
Re: synchronized vs. C volatile
On Mon, Aug 9, 2010 at 7:29 AM, BCS wrote: > Hello SK, > >> Does 'synchronized' mean the exact same thing as the C 'volatile' >> qualifier when applied to basic types? >> As in: >> synchronized int x; > > I'm reasonably sure that it doesn't. I think synchronized invokes a mutex > for access and C's volatile just suppresses some optimizations. > > -- > ... < > Andrei's book does not list volatile as a keyword in D. I'm at a loss unless 'synchronized' performs double duty as volatile. For example, device status registers are "const volatile" in C/C++. The compiler disallows writes and does not optimize away reads. Mutexes are irrelevant and for that matter the processor may not (and need not) even support atomic instructions. -steve
Re: synchronized vs. C volatile
On Mon, Aug 9, 2010 at 6:25 AM, dsimcha wrote:
> == Quote from SK (s...@metrokings.com)'s article
>> Does 'synchronized' mean the exact same thing as the C 'volatile'
>> qualifier when applied to basic types?
>> As in:
>> synchronized int x;
>
> They're completely different. synchronized is basically a scoped mutex and
> applies to a statement, not a variable declaration. I have no idea what your
> example does, but it probably shouldn't even compile. Volatile just prevents
> certain compiler optimizations that can interfere with updates to a variable
> from
> other hardware besides the CPU and is useful for things like device drivers.
>
>
Sounds right to me too. But the compiler warns about deprecated
'volatile'. Is the warning a mistake? Volatile has an important
place in a systems language and I'd rather not mess with tradition
here.
$ cat main.d
int main()
{
volatile int x = 1;
synchronized int y = 1;
return 0;
}
$ dmd -w -wi main.d
main.d(4): volatile statements deprecated; used synchronized statements instead
synchronized vs. C volatile
Does 'synchronized' mean the exact same thing as the C 'volatile' qualifier when applied to basic types? As in: synchronized int x;
Re: getopt & single-letter options with parameters
On Aug 7, 2010, at 4:22 PM, Andrei Alexandrescu > wrote:
On 08/07/2010 05:55 PM, Adrian Matoga wrote:
Hi,
Is it by design that single-letter option needs to be glued to its
argument, like "-ofilename", or is it a bug in implementation?
Source:
import std.stdio;
import std.getopt;
void main(string[] args)
{
string outputFile;
getopt(args,
config.passThrough,
"o|output-filename", &outputFile);
writeln(args);
writeln("'" ~ outputFile ~ "'");
}
Results:
>test.exe -o somename
test.exe somename
''
>test.exe -osomename
test.exe
'somename'
Regards,
Adrian Matoga
It's by design in order to avoid confusion with parameterless
options. Your example works with either of these invocations:
./prog -ofilename
./prog -o=filename
./prog --o=filename
but not others.
Andrei
The prevailing convention is to allow whitespace in this case. Would
you reconsider?
Sorry for the accidental null post earlier.
-steve
Re: getopt & single-letter options with parameters
On Aug 7, 2010, at 4:22 PM, Andrei Alexandrescu > wrote: It's by design in order to avoid confusion with parameterless options. Your example works with either of these invocations: ./prog -ofilename ./prog -o=filename ./prog --o=filename but not others. Andrei
Re: Build farm(er)
Hello Andrei, On Thu, Aug 5, 2010 at 6:59 PM, Andrei Alexandrescu wrote: > and everything is built from source all the way to uploading the installers > for all OSs to the website and updating html files accordingly. > How about CDash? http://www.cdash.org/cdash/project/about.html CMake+CTest+CDash provide integrated build, test and reporting. For example, here the dashboard for CDash itself: http://www.cdash.org/CDash/index.php?project=CDash That said, I have not tried CDash myself, though I'm a user and fan of the first two pieces: CMake and CTest. Speaking of which, I'm working on CMake for D2, which seems to have lost its maintainer. Also, I highly recommend using virtual machines rather than bare metal for a build farm -- easier and much more economical. Regards, -steve
