On 26/09/2013 16:13, Jacob Carlborg wrote:
On 2013-09-26 14:22, Bruno Medeiros wrote:
Why would that be nice? It saves you the small hassle of downloading
GCC+GDB+GDC into it's own installation. With precompiled binaries for
your platform, that should take only 15 minutes of your time and then
you're set (well, a bit again when you want to update).
To avoid what you just listed, that's why it's nice :). Why wouldn't I
want to use the default tool chain.
It's just if the 15 minutes setup were the only issue, that's pretty
insignificant for any serious development. There are issues and
limitations with the D toolchain that are an order of magnitude (maybe
even *two* orders) more important/troublesome.
But having up-to-date tools with up-to-date functionality far
outweights in
benefits that small hassle.
I do have up-to-date tools with with up-to-date functionality, it's just
a different tool chain than GCC. Also, I would consider the LLVM tool
chain more up-to-date than GCC.
Or are there downsides to that approach? Does using the GCC toolchain on
Mac OS X have shortcomings in functionality? The only reasons I can
think so far, is if you want to work with LLVM/LLDB specifically (not
merely because it's the compiler that ships with OSX, but because you
prefer LLDB over GDB). Or if you want to use OSX specific libraries in
your D application? (with might somewhat be tied to the OSX toolchain)
As I said, I think that "sudo" is required to run GDB from Macports.
That's quite annoying, if that's the case.
True, if that's the case.
The GCC tool chain is missing a couple of features which the LLVM tool
chain now has. These are mainly C/C++ and Objective-C/C++ features:
* Blocks
* Modules
* A bunch of new Objective-C features
* TLS
The ones that affect D would be blocks and TLS.
It should be possible to use a C function, from D, which uses blocks.
One just have to figure out what the runtime representation of a block
looks like.
In Mac OS X 10.7 Apple introduce native support for TLS. The compiler
and linker parts were only implemented in the LLVM tool chain. LDC can
take advantage of this. GDC doesn't support native TLS on Mac OS X and,
as far as I recall, it doesn't even support emulated TLS which DMD does.
I might end up needing a C library that only compiles with the LLVM tool
chain. Such as one which uses blocks.
I also might want to use Mac OS X specific libraries. GUI applications
are a good examples of this.
Also, if D is ever going to work in iOS, I think the best bet is on LDC.
Because it uses the same tool chain as Apple does.
Blocks is a C language extension by Apple. I suspect that Modules is the
same, although I couldn't google it quickly. Therefore this doesn't
really affect pure D development. Rather, it's significance would be the
same as of the use case of using Mac OS X specific libraries.
GDC does not supporting TLS (not even emulated TLS)?? That is a major
problem though!! :( It's more than major, it pretty much breaks D
development on Mac for anything other than just toy projects (with GDC
that is).
Well, I'm pretty much conviced anyways: better to support LLDB to have
the best debugging support for Mac OS X. I'm not too annoyed since I
planned to support LDC/LLDB anyways, as it seems a worthwhile
platform/compiler as much as GDC even for other platforms. But it would
still have been nice if GDC where to work properly on Mac.
--
Bruno Medeiros - Software Engineer
