On 2 April 2012 16:48, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> Hello all,
>
> First, congratulations to the GDC team -- I'm playing with D for the first time in quite a while thanks to the up-to-date gdc 4.6 packages in the upcoming Ubuntu LTS release.  It's great to see that D 2.0 now has this kind of mainstream distro support.
>
> Anyway, a question about the gdc versus gdmd interfaces to the compiler.  I've noticed that compiling with the options
>
>  gdmd -O -release -inline
>

This is equivalent to:

gdc -O3 -frelease -finline-functions




Regards
-- 
Iain Buclaw

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

On 02/04/12 18:34, Iain Buclaw wrote:
> This is equivalent to:
>
> gdc -O3 -frelease -finline-functions

Ah; thanks!  In fact -O2 -frelease suffices, it turns out.

Trass3r wrote:
> Basically -frelease is missing.
> Use -vdmd with gdmd to see the command.

Thanks, I'd missed that option on the man pages. :-\

According to this the actual result of gdmd -O -release -inline is:

  gdc -O3 -fweb -frelease -finline-functions

Follow-up question -- has there been any work on integration of gdc/gdmd in the GNU Autotools (autoconf, automake ...)?  If not, any recommendation of a good build system for use with gdc?

Thanks and best wishes,

    -- Joe

On 02-04-2012 23:17, Joseph Rushton Wakeling wrote:
> On 02/04/12 18:34, Iain Buclaw wrote:
>> This is equivalent to:
>>
>> gdc -O3 -frelease -finline-functions
>
> Ah; thanks! In fact -O2 -frelease suffices, it turns out.
>
> Trass3r wrote:
>> Basically -frelease is missing.
>> Use -vdmd with gdmd to see the command.
>
> Thanks, I'd missed that option on the man pages. :-\
>
> According to this the actual result of gdmd -O -release -inline is:
>
> gdc -O3 -fweb -frelease -finline-functions
>
> Follow-up question -- has there been any work on integration of gdc/gdmd
> in the GNU Autotools (autoconf, automake ...)? If not, any
> recommendation of a good build system for use with gdc?
>
> Thanks and best wishes,
>
> -- Joe

The Waf meta build system has good support for both GDC and LDC.

-- 
- Alex

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

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.

-- 
- Alex

On Mon, Apr 2, 2012 at 9:04 PM, Alex Rønne Petersen <xtzgzorex@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.
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

On 03-04-2012 04:35, Andrew Wiley wrote:
> On Mon, Apr 2, 2012 at 9:04 PM, Alex Rønne Petersen<xtzgzorex@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).

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).

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.

-- 
- Alex

On Tue, Apr 3, 2012 at 1:37 AM, Alex Rønne Petersen <xtzgzorex@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@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.

On 3 April 2012 09:23, Andrew Wiley <wiley.andrew.j@gmail.com> wrote:
> On Tue, Apr 3, 2012 at 1:37 AM, Alex Rønne Petersen <xtzgzorex@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@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';

On 2012-04-03 11:06, Iain Buclaw wrote:

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

I would say that Make is the most horrible build system I've ever used. I guess I have most problem with the makefiles and their syntax. I mean, why would I need to specify all the files I want to compile myself. Have a look at the Phobos posix makefile for example. You need to specify the files more than once, that's even more stupid. DSSS was a good build system, you just had to say:

[main.d]

For an executable or

[lib]

For a library. It will then automatically figure out all dependencies.

-- 
/Jacob Carlborg