On 10/22/2012 09:41 PM, H. S. Teoh wrote:
> I've managed to build git GDC on Debian unstable (64-bit), and have just
> added the instructions to:
>
> 	http://gdcproject.org/wiki/Installation
>
> I used the gdc-4.7 branch of GDC git, which unfortunately has a bug in
> the update-gcc.sh script, so your best bet is to checkout my fixed fork:
>
> 	https://github.com/quickfur/GDC/tree/gdc-4.7-update-fix

Oh, cool.  Thanks for that.  I will have a go some time in the next days and report back how it goes.

> If you want, I can send you the build script I have, that contains all
> the commands (well, hopefully all) to unpack, patch, and build the
> Debian GCC sources (patched with GDC, of course). If all goes well, it
> should provide you with a working GDC. :)

I'll give it a go with your branch first (or hopefully, with an update that has it merged in) and get back to you if I run into trouble.

Just a query -- the Raspberry Pi instructions have some notes on tweaking the Debian patch script -- did you have to do this, or did you just leave it as-is?

> This is only the gdc-4.7 branch, though; git master isn't building on my
> system because the gcc build script mistakes Walter's pathological
> naming of C++ source files with a .c extension for actual C code, which
> causes it to invoke the wrong compiler and produce reams and reams of
> compile errors before dying miserably. I'm still trying to figure out
> how to fix this.

I take it Walter is resistant to a rename for the frontend source files? :-\

Thanks again and best wishes,

     -- Joe

On 22 October 2012 20:41, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Mon, Oct 22, 2012 at 09:15:01PM +0200, Joseph Rushton Wakeling wrote:
>> On 10/22/2012 08:14 PM, Alex Rønne Petersen wrote:
>> >It is, and has been for months.
>>
>> The upstream source is up to date, but there are no packaged versions that I'm aware of and building it from source on a Debian/Ubuntu system has proven somewhat tricky (not just for me, see current d.gnu discussion).
>>
>> Not demanding a solution, just saying. :-)
>
> I've managed to build git GDC on Debian unstable (64-bit), and have just
> added the instructions to:
>
>         http://gdcproject.org/wiki/Installation
>
> I used the gdc-4.7 branch of GDC git, which unfortunately has a bug in the update-gcc.sh script, so your best bet is to checkout my fixed fork:
>
>         https://github.com/quickfur/GDC/tree/gdc-4.7-update-fix
>
> I've submitted a pull request for the fork, but that was only today, so it probably won't get committed until a bit later.
>
> If you want, I can send you the build script I have, that contains all
> the commands (well, hopefully all) to unpack, patch, and build the
> Debian GCC sources (patched with GDC, of course). If all goes well, it
> should provide you with a working GDC. :)
>
> This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this.
>

It shoudln't be doing that - I would instead question what revision of GCC you are currently using.  As it's switch to C++ as the default compiler around 2 months ago.

Regards
-- 
Iain Buclaw

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

On Mon, Oct 22, 2012 at 09:53:40PM +0200, Alex Rønne Petersen wrote:
> On 22-10-2012 21:41, H. S. Teoh wrote:
[...]
> >This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this.
> 
> Might want to poke Iain about this. Sounds like a missing -x c++.

Where may he be poked at? :)


> >(P.S. GCC's build system seriously needs a major overhaul. It's extremely fragile and completely unfriendly when it comes to telling you what the problem is when it fails. The error message is often faaaar away from the real source of the problem, and often has no indication whatsoever as to what the nature of the real problem is. I spent at least 2 whole days fighting with it before I figured out how to pacify it enough for the build to succeed. I wouldn't wish this experience on anyone.)
> 
> Unfortunately, one does not simply "overhaul" the GCC build system. It consists of thousands upon thousands of lines of logic to configure, build, and test GCC for all sorts of obscure scenarios

Yes, written in m4, bash, and that hilariously huge Makefile (or its automake progenitors thereof). It's completely opaque to me.


> (have you ever done a Canadian cross build of GCC?), most of which other build systems couldn't possibly get right.
[...]

<rant>
Well, this is just my biased arrogant opinion, but the root of the
problem is that make is an antiquated overly-simplistic script that has
long outlived its time, but due to historical reasons still survive
festering under the layers of patches that it has acquired over the
course of its sad life. Automake and its ilk are just yet another
(system of) layer of patches upon the same broken system that doesn't
address the fundamental design flaws in make. It's an edifice of cards
that nobody dares touch because, well, it would take too much effort to
reproduce all the tiny obscure cases it has been tweaked for over the
years. But it's nonetheless a nigh unmaintainable fortress of cards that
will collapse at the slightest provocation in the most unhelpful of
ways. It's like implementing the whole of Windows 8 in K&R C. In this
day and age, one would *think* we could do better, but no, this fossil
from the 70's still shambles on, to the unnecessary suffering of
countless generations of new programmers.
</rant>


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill

On Mon, Oct 22, 2012 at 09:54:32PM +0200, Joseph Rushton Wakeling wrote:
> On 10/22/2012 09:41 PM, H. S. Teoh wrote:
[...]
> Just a query -- the Raspberry Pi instructions have some notes on tweaking the Debian patch script -- did you have to do this, or did you just leave it as-is?

Hmm, I *thought* I left it as-is, but apparently I did have the tweak in the patch script (and it doesn't work if you leave it out).  I'll update the wiki.


> >This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this.
> 
> I take it Walter is resistant to a rename for the frontend source files? :-\
[...]

>From what I gather, yes.


T

-- 
Famous last words: I *think* this will work...

On Mon, Oct 22, 2012 at 09:15:41PM +0100, Iain Buclaw wrote:
> On 22 October 2012 20:41, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
[...]
> > This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this.
> >
> 
> It shoudln't be doing that - I would instead question what revision of GCC you are currently using.  As it's switch to C++ as the default compiler around 2 months ago.
[...]

Does gdc git master require gcc-4.8 to build (I mean, 4.8 installed as default compiler on the system, not just 4.8 sources)?

% gcc --version
gcc (Debian 4.7.2-4) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/mnt/1/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-4)



T

-- 
Let's call it an accidental feature. -- Larry Wall

On 22 October 2012 21:46, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Mon, Oct 22, 2012 at 09:15:41PM +0100, Iain Buclaw wrote:
>> On 22 October 2012 20:41, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> [...]
>> > This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this.
>> >
>>
>> It shoudln't be doing that - I would instead question what revision of GCC you are currently using.  As it's switch to C++ as the default compiler around 2 months ago.
> [...]
>
> Does gdc git master require gcc-4.8 to build (I mean, 4.8 installed as default compiler on the system, not just 4.8 sources)?
>
> % gcc --version
> gcc (Debian 4.7.2-4) 4.7.2
> Copyright (C) 2012 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

No

-- 
Iain Buclaw

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

On Mon, 2012-10-22 at 12:54 -0700, H. S. Teoh wrote:
[…]
> Does it use the dmd tool by default? How do I select the gdc tool instead? I tried env.Append(tools = 'gdc') but it didn't make any difference.

I will have to check what the default tool is, in the case where multiple valid D toolchains are installed, there may be a problem there.

environment = Environment(tools=['gcc', 'gnulink', 'gdc'])

is known to work. There are issues here that we are trying to fix relating to how C, C++, Fortran and D all interwork. An upshot of the problem is that, for now, the gdc tool must come last in the sequence. :-(( I know, but…

[…]
> If there's an easy way to select which tool to use, then it's good enough for me. Having a tool that tries to guess what you want usually ends up doing the wrong thing, especially since I have both compilers installed and often switch between them in different projects for testing, comparison, profiling, etc., purposes.

See above :-)

[…]
> I'm going to take a shot at building a .deb for the latest git gdc-4.7 branch, which AFAIK should support at least 2.059 (and maybe 2.060?). It's probably non-trivial, as the debian gcc build scripts are a tangled labyrinth I've yet to unravel. :)

You can certainly put me on the list of people to test such a thing.

My only need is that it must be harmonious with the Debian Unstable install so that it can be installed and uninstalled without disrupting the standard Debian 4.7.

Thanks.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 2012-10-22 at 13:19 -0700, H. S. Teoh wrote:
[…]
> <rant>
> Well, this is just my biased arrogant opinion, but the root of the
> problem is that make is an antiquated overly-simplistic script that has
> long outlived its time, but due to historical reasons still survive
> festering under the layers of patches that it has acquired over the
> course of its sad life. Automake and its ilk are just yet another
> (system of) layer of patches upon the same broken system that doesn't
> address the fundamental design flaws in make. It's an edifice of cards
> that nobody dares touch because, well, it would take too much effort to
> reproduce all the tiny obscure cases it has been tweaked for over the
> years. But it's nonetheless a nigh unmaintainable fortress of cards that
> will collapse at the slightest provocation in the most unhelpful of
> ways. It's like implementing the whole of Windows 8 in K&R C. In this
> day and age, one would *think* we could do better, but no, this fossil
> from the 70's still shambles on, to the unnecessary suffering of
> countless generations of new programmers.
> </rant>

Make was a revelation and a revolution in 1977.

Surprisingly Make remains very useful for small tasks not requiring cross-platform portability.

Autotools is very UNIX biased.

CMake keeps Make going. Just.

Waf and SCons work well across platforms for C, C++, D, Fortran, LaTeX, Vala, but not JVM-based languages.

Gradle rules on the JVM, along with SBT and Leiningen. Gradle is also trying to invade the C++ space.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 23 October 2012 at 09:07:34 UTC, Russel Winder wrote:
> On Mon, 2012-10-22 at 13:19 -0700, H. S. Teoh wrote:
> […]
>> <rant>
>> Well, this is just my biased arrogant opinion, but the root of the
>> problem is that make is an antiquated overly-simplistic script that has
>> long outlived its time, but due to historical reasons still survive
>> festering under the layers of patches that it has acquired over the
>> course of its sad life. Automake and its ilk are just yet another
>> (system of) layer of patches upon the same broken system that doesn't
>> address the fundamental design flaws in make. It's an edifice of cards
>> that nobody dares touch because, well, it would take too much effort to
>> reproduce all the tiny obscure cases it has been tweaked for over the
>> years. But it's nonetheless a nigh unmaintainable fortress of cards that
>> will collapse at the slightest provocation in the most unhelpful of
>> ways. It's like implementing the whole of Windows 8 in K&R C. In this
>> day and age, one would *think* we could do better, but no, this fossil
>> from the 70's still shambles on, to the unnecessary suffering of
>> countless generations of new programmers.
>> </rant>
>
> Make was a revelation and a revolution in 1977.
>
> Surprisingly Make remains very useful for small tasks not requiring
> cross-platform portability.
>
> Autotools is very UNIX biased.
>
> CMake keeps Make going. Just.
>
> Waf and SCons work well across platforms for C, C++, D, Fortran, LaTeX,
> Vala, but not JVM-based languages.
>
> Gradle rules on the JVM, along with SBT and Leiningen. Gradle is also
> trying to invade the C++ space.


Even worse is having new generations of developers learning that the 70's way of Make and Autotools is the way to go.

--
Paulo

On 10/23/2012 11:06 AM, Russel Winder wrote:
> Waf and SCons work well across platforms for C, C++, D, Fortran, LaTeX,
> Vala, but not JVM-based languages.

I wasn't familiar with SCons, though I'd heard you and others mention it before -- just took a look -- it looks like a promising tool.  Thanks very much for the introduction!