Compiling with gdc vs. gdmd

[Iain Buclaw]

On 3 April 2012 09:23, Andrew Wiley <wiley.andrew.j at gmail.com> 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.
>
>> 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.
>
>> 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.

Make is fairly simple.  What makes it the complex beast it is - IMO -
when used in conjunction with autotools.  :-)



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';