Compiling with gdc vs. gdmd

[Alex Rønne Petersen]

On 03-04-2012 11:06, Iain Buclaw wrote:
> 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.  :-)
>
>
>

No argument there. It *really* is simple. The problem is that it's so 
simple that when you start doing advanced stuff, you basically enter 
shell land where nothing is portable...

-- 
- Alex