Compiling with gdc vs. gdmd

Alex Rønne Petersen xtzgzorex at gmail.com
Tue Apr 3 03:50:00 PDT 2012


On 03-04-2012 10:23, Andrew Wiley wrote:
> On Tue, Apr 3, 2012 at 1:37 AM, Alex Rønne Petersen<xtzgzorex at gmail.com>  wrote:
>> On 03-04-2012 04:35, Andrew Wiley wrote:
>>>
>>> On Mon, Apr 2, 2012 at 9:04 PM, Alex Rønne Petersen<xtzgzorex at gmail.com>
>>>   wrote:
>>>>
>>>> On 03-04-2012 01:19, Joseph Rushton Wakeling wrote:
>>>>
>>>>>
>>>>> On 03/04/12 00:48, Alex Rønne Petersen wrote:
>>>>>>
>>>>>>
>>>>>> The Waf meta build system has good support for both GDC and LDC.
>>>>>
>>>>>
>>>>>
>>>>> I'm reluctant to use Waf due to the issues described here ... :-(
>>>>> http://lists.debian.org/debian-devel/2010/02/msg00714.html
>>>>>
>>>>
>>>> Which ones in particular? Debian lacking a system-level Waf doesn't seem
>>>> like a huge issue to me.
>>>>
>>>
>>> Unless you want someone else to build your software.
>>
>>
>> Include the Waf binary with your software. It's designed to be small so that
>> you can do this.
>>
>>
>>> My biggest frustration with open source software and specifically with
>>> meta build systems is that I don't want to learn a scripting language
>>> or a scripting language's package manager just to build and use a
>>> piece of software in a completely unrelated language, and if there's
>>> no pre-packaged version of a build system, I'm not going to take the
>>> time to figure out how to use whatever package manager language X uses
>>> to install that build system and all dependencies. Most likely the
>>> dependencies and build system will wind up in my home directory, which
>>> is hackish at best, and it'll all sit there forever and clutter up my
>>> home directory because I'll never touch that package manager again.
>>> For a build that will be set up exactly once and modified extremely
>>> rarely after the first month or so, how is this an improvement over
>>> this Makefile that can already do perfect incremental builds:
>>>
>>> TARGET  := someexecutable
>>> SRCS    := $(shell find -type f -name '*.d')
>>> OBJS    := ${SRCS:.d=.o}
>>> DEPS    := ${SRCS:.d=.dep}
>>> XDEPS   := $(wildcard ${DEPS})
>>> DC      := gdc
>>>
>>> DFLAGS = -Wall -Werror -g -O2
>>> LDFLAGS =
>>> LIBS    = -lpthread
>>>
>>> .PHONY: all clean distclean
>>> all:: ${TARGET}
>>>
>>> ifneq (${XDEPS},)
>>> include ${XDEPS}
>>> endif
>>>
>>> ${TARGET}: ${OBJS}
>>>      ${DC} ${LDFLAGS} ${DFLAGS} -o $@ $^ ${LIBS}
>>>
>>> ${OBJS}: %.o: %.d %.dep
>>>      ${DC} ${DFLAGS} -o $@ -c $<
>>>
>>> ${DEPS}: %.dep: %.d
>>>      ${DC} ${DFLAGS} -fsyntax-only -fmake-mdeps=$@ $<
>>>      sed -i 's:$(notdir ${<:.d=.o}):${<:.d=.o}:g' $@
>>>
>>> clean::
>>>      -rm -f ${OBJS} ${DEPS} ${TARGET}
>>>
>>> distclean:: clean
>>
>>
>> I understand your frustration about having to learn another language.
>> Learning a language is always an expensive task. But people don't
>> necessarily know Make syntax, just as they don't necessarily know Python, or
>> whatever (and I might add that Make can get very frustrating - the
>> requirement to use hard tabs is extremely annoying and unintuitive).
>>
> Either way, you're going to set up your build system once and rarely
> change it, so the syntax isn't really what bothers me. What matters
> isn't really the difficulty of setting up the build system, it's the
> difficulty of going from blank slate to finished binary for someone
> who has just downloaded the code. For better or worse, systems like
> make are ubiquitous, whereas with other build systems, I have to go
> install it. That still isn't too bad if there's a package I can
> install in the package manager I already use to manage my system, but
> when the developers actively discourage that convenience, I become
> concerned.

With Waf, the idea is that the Waf binary sits in your source control 
repository, so building is easy.

>
>> A problem with systems like Make is that it is hard to keep Makefiles
>> portable. It doesn't take much to accidentally introduce some sort of
>> platform/shell/compiler dependency. Python, as a programming language, at
>> least helps abstract most of these things away (for instance, shell syntax).
>
> Thanks to MSYS/MinGW, that Makefile I quoted runs on both Windows and
> Linux. It depends on find and sed. The dependency on find is easily
> removed if you're not too lazy to list source files like I am, and the
> sed dependency can be removed if you don't care too much about perfect
> incremental builds (there's probably a Windows shell equivalent, I
> haven't checked).
> I don't have a Mac, but I wouldn't expect sed/find to be an issue there.

It's a trivial Makefile. If you begin to add packaging, testing, etc 
then Makefiles become hell very quickly.

>
>> Anyway, as for what 'language' to use, it all comes down to your personal
>> situation. If you know Python, using something like Waf is completely
>> inexpensive, just as using Make is inexpensive if you know the Make syntax.
>
> I don't know Make syntax and I have no interest in learning it. What
> you see above was cobbled together once from a variety of online
> sources, tested thoroughly, and reused abusively because the only
> thing necessary to use it was to copy it to a new project. No large
> language installations, no oversized frameworks or tools. It works
> with most linux distributions out of the box, and on Windows you
> already have to install GCC (which includes make) to get GDC.

But that also indicates that you're going to have trouble the moment you 
decide to go further and add packaging, testing, documentation 
generation of sorts, etc.

I'm not sure if you're getting at Waf specifically here, but if you are, 
I don't think that's quite fair, since Waf is ~85 KB and is meant to sit 
in your source control repository. Also, Waf works on Windows/Linux/Mac 
(I have tested this), and probably many other systems where Python and a 
D compiler exists.

You might argue that Python is a huge dependency, but really, Windows is 
close to the only OS that doesn't ship with Python or otherwise requires 
it for most things.

-- 
- Alex


More information about the D.gnu mailing list