www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD build

reply Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Is there a reason for using g++ to compile and link the C code of DMD?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Dec 28 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-28 16:18, Russel Winder wrote:
 Is there a reason for using g++ to compile and link the C code of DMD?

As far as I know it doesn't work with Clang. Did you have any other compiler in mind? -- /Jacob Carlborg
Dec 28 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-12-28 18:12, Nicolas Sicard wrote:

 Actually it works with Clang (v4.5), albeit with many warnings. Just
 pass HOST_CC=clang++ to the makefile.

I see, thanks. -- /Jacob Carlborg
Dec 28 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 28 December 2012 at 15:18:17 UTC, Russel Winder wrote:
 Is there a reason for using g++ to compile and link the C code 
 of DMD?

DMD is actually written in C++, Walter just chose file names ending in .c for some strange reason. David
Dec 28 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/12 10:51 AM, Russel Winder wrote:
 On Fri, 2012-12-28 at 16:30 +0100, David Nadlinger wrote:
 On Friday, 28 December 2012 at 15:18:17 UTC, Russel Winder wrote:
 Is there a reason for using g++ to compile and link the C code
 of DMD?

DMD is actually written in C++, Walter just chose file names ending in .c for some strange reason.

I can understand using C++ rather than C, but (sorry Walter) naming the files X.c is a f###### stupid idea.

From the HSP (Holiday Spirit Police): s/f###### stupid/odd/ Andrei
Dec 28 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-28 17:27, Andrei Alexandrescu wrote:

 From the HSP (Holiday Spirit Police):

 s/f###### stupid/odd/

I agree with Russel in this case. -- /Jacob Carlborg
Dec 28 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/12 1:34 PM, Jacob Carlborg wrote:
 On 2012-12-28 17:27, Andrei Alexandrescu wrote:

 From the HSP (Holiday Spirit Police):

 s/f###### stupid/odd/

I agree with Russel in this case.

I wasn't disagreeing. Andrei
Dec 28 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-28 16:30, David Nadlinger wrote:

 DMD is actually written in C++, Walter just chose file names ending in
 .c for some strange reason.

Oh, he means like that. That's kind of strange. -- /Jacob Carlborg
Dec 28 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/28/2012 7:51 AM, Russel Winder wrote:
 On Fri, 2012-12-28 at 16:30 +0100, David Nadlinger wrote:
 DMD is actually written in C++, Walter just chose file names
 ending in .c for some strange reason.

I can understand using C++ rather than C, but (sorry Walter) naming the files X.c is a f###### stupid idea. The standard name strategy is one of X.C, X.cc, or X.cpp, for very good reasons.

Yeah, the standard name is .C, or is it .cc, or is it .cpp, or is it .cxx (I've seen that "standard" one, too), and are headers .hxx or is the standard .hpp or whatever. Hell, I've even seen .c++ It's about the most non-standard "standard" I've ever encountered :-)
Dec 28 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/12 2:21 PM, John Colvin wrote:
 On Friday, 28 December 2012 at 19:06:05 UTC, Walter Bright wrote:
 On 12/28/2012 7:51 AM, Russel Winder wrote:
 On Fri, 2012-12-28 at 16:30 +0100, David Nadlinger wrote:
 DMD is actually written in C++, Walter just chose file names
 ending in .c for some strange reason.

I can understand using C++ rather than C, but (sorry Walter) naming the files X.c is a f###### stupid idea. The standard name strategy is one of X.C, X.cc, or X.cpp, for very good reasons.

Yeah, the standard name is .C, or is it .cc, or is it .cpp, or is it .cxx (I've seen that "standard" one, too), and are headers .hxx or is the standard .hpp or whatever. Hell, I've even seen .c++ It's about the most non-standard "standard" I've ever encountered :-)

I guess the convention is "Anything that is clear as to language the file contains". ".cpp" and ".cxx" are both very good at that. ".cc" is less good, ".C" is even worse. All of them are better than ".c"

I wondered how much work it takes so I just created a fork that renames all relevant .c files to .cpp. https://github.com/andralex/dmd/tree/extensions Works on OSX just swell and took me little more than 5 minutes. Anyone wants to take that over and make it work for Windows too? Andrei
Dec 28 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/12 4:39 PM, Brad Roberts wrote:
 What impact does this have on the open pull requests?  If it's going to
 suddenly break every one of them, then I think it's a particularly bad
 idea.

There are dozens of open pull requests and if worse comes to worst people will agree to fix their requests because the request for changing extensions has enjoyed considerable popularity.
 The benefit is debatable and the cost is pretty annoying.

The benefit is we'll avoid resurrecting a debate that comes back and again. Technically there's no reason to move with the change, but right now we're wasting time and burning through karma. Making the change shows respect for the community and for working together in an environment that has few gratuitous idiosyncrasies. Let's do it. Thanks, Andrei
Dec 28 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:kbl3eh$2qe8$1 digitalmars.com...
 On 12/28/12 4:39 PM, Brad Roberts wrote:
 What impact does this have on the open pull requests?  If it's going to
 suddenly break every one of them, then I think it's a particularly bad
 idea.

There are dozens of open pull requests and if worse comes to worst people will agree to fix their requests because the request for changing extensions has enjoyed considerable popularity.
 The benefit is debatable and the cost is pretty annoying.

The benefit is we'll avoid resurrecting a debate that comes back and again. Technically there's no reason to move with the change, but right now we're wasting time and burning through karma. Making the change shows respect for the community and for working together in an environment that has few gratuitous idiosyncrasies. Let's do it. Thanks, Andrei

You want to screw up over a hundred open pull requests and destroy the commit history... for what? Because every year or so someone complains about the file extensions? Anyone that takes longer than 5 minutes to work out what's going on probably shouldn't be trying to change the compiler's build process. Put a note in the readme, the makefile, and/or the wiki page on building the compiler, and leave the source alone. Daniel.
Dec 28 2012
next sibling parent reply Marco Nembrini <marco.nembrini.co gmail.com> writes:
On 29.12.2012 12:18, Daniel Murphy wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:kbl3eh$2qe8$1 digitalmars.com...
 On 12/28/12 4:39 PM, Brad Roberts wrote:
 What impact does this have on the open pull requests?  If it's going to
 suddenly break every one of them, then I think it's a particularly bad
 idea.

There are dozens of open pull requests and if worse comes to worst people will agree to fix their requests because the request for changing extensions has enjoyed considerable popularity.
 The benefit is debatable and the cost is pretty annoying.

The benefit is we'll avoid resurrecting a debate that comes back and again. Technically there's no reason to move with the change, but right now we're wasting time and burning through karma. Making the change shows respect for the community and for working together in an environment that has few gratuitous idiosyncrasies. Let's do it. Thanks, Andrei

You want to screw up over a hundred open pull requests and destroy the commit history... for what? Because every year or so someone complains about the file extensions? Anyone that takes longer than 5 minutes to work out what's going on probably shouldn't be trying to change the compiler's build process. Put a note in the readme, the makefile, and/or the wiki page on building the compiler, and leave the source alone. Daniel.

Nobody answered the important question: does it "break" pull requests? In my (limited) understanding git supports renames and pulls will be "broken" in the same way the are when there's a new commit on the original repo: people will just have to rebase their changes on it. I did some googling and found nobody complaining about this problem, so I assume there's some way to avoid it.
Dec 28 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-29 03:39, Bernard Helyer wrote:

 IIRC, Git can figure out if a raw renamed file (a new file from git's
 perspective) is a rename of an old file if the contents are the
 same as a recently removed file above a certain threshold (70 percentish).

 Considering the contents of the files shouldn't change at all, I
 _think_ git should be able to figure out what's happened.

Git can figure out it's a rename even if some of the content has changed. -- /Jacob Carlborg
Dec 29 2012
prev sibling parent Martin Nowak <dawg dawgfoto.de> writes:
 I would expect rebasing to fix it trivially so long as git mv was used rather
 than renaming the file with the OS' commands, but I don't know for sure.

 - Jonathan M Davis

Git doesn't record renamings but uses a heuristic check for similarity instead. Rebasing will be trivial as long as the rename detection succeeds. Once the '.cc' files differ too much from the '.c' base in an open pull request it'll cause a delete/modify conflict. http://stackoverflow.com/questions/2314437/resolve-conflict-delete-modify-in-git
Dec 30 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/12 8:18 PM, Daniel Murphy wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:kbl3eh$2qe8$1 digitalmars.com...
 On 12/28/12 4:39 PM, Brad Roberts wrote:
 What impact does this have on the open pull requests?  If it's going to
 suddenly break every one of them, then I think it's a particularly bad
 idea.

There are dozens of open pull requests and if worse comes to worst people will agree to fix their requests because the request for changing extensions has enjoyed considerable popularity.
 The benefit is debatable and the cost is pretty annoying.

The benefit is we'll avoid resurrecting a debate that comes back and again. Technically there's no reason to move with the change, but right now we're wasting time and burning through karma. Making the change shows respect for the community and for working together in an environment that has few gratuitous idiosyncrasies. Let's do it. Thanks, Andrei

You want to screw up over a hundred open pull requests and destroy the commit history...

I used git mv, which to my understanding preserves commit history and makes pull requests easy to fix via a rebase: http://stackoverflow.com/questions/2641146/handling-file-renames-in-git Andrei
Dec 28 2012
prev sibling parent Mike Wey <mike-wey example.com> writes:
On 12/28/2012 10:39 PM, Brad Roberts wrote:
 What impact does this have on the open pull requests?  If it's going to
 suddenly break every one of them, then I think it's a particularly bad
 idea.  The benefit is debatable and the cost is pretty annoying.

You could always pull some of the requests into your local copy to check if it's causing a lot of conflicts or not. -- Mike Wey
Dec 29 2012
prev sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
On Fri, 28 Dec 2012, Andrei Alexandrescu wrote:

 On 12/28/12 2:21 PM, John Colvin wrote:
 On Friday, 28 December 2012 at 19:06:05 UTC, Walter Bright wrote:
 On 12/28/2012 7:51 AM, Russel Winder wrote:
 On Fri, 2012-12-28 at 16:30 +0100, David Nadlinger wrote:
 DMD is actually written in C++, Walter just chose file names
 ending in .c for some strange reason.

I can understand using C++ rather than C, but (sorry Walter) naming the files X.c is a f###### stupid idea. The standard name strategy is one of X.C, X.cc, or X.cpp, for very good reasons.

Yeah, the standard name is .C, or is it .cc, or is it .cpp, or is it .cxx (I've seen that "standard" one, too), and are headers .hxx or is the standard .hpp or whatever. Hell, I've even seen .c++ It's about the most non-standard "standard" I've ever encountered :-)

I guess the convention is "Anything that is clear as to language the file contains". ".cpp" and ".cxx" are both very good at that. ".cc" is less good, ".C" is even worse. All of them are better than ".c"

I wondered how much work it takes so I just created a fork that renames all relevant .c files to .cpp. https://github.com/andralex/dmd/tree/extensions Works on OSX just swell and took me little more than 5 minutes. Anyone wants to take that over and make it work for Windows too? Andrei

What impact does this have on the open pull requests? If it's going to suddenly break every one of them, then I think it's a particularly bad idea. The benefit is debatable and the cost is pretty annoying.
Dec 28 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-12-28 at 16:30 +0100, David Nadlinger wrote:
 On Friday, 28 December 2012 at 15:18:17 UTC, Russel Winder wrote:
 Is there a reason for using g++ to compile and link the C code=20
 of DMD?

DMD is actually written in C++, Walter just chose file names=20 ending in .c for some strange reason.

I can understand using C++ rather than C, but (sorry Walter) naming the files X.c is a f###### stupid idea. The standard name strategy is one of X.C, X.cc, or X.cpp, for very good reasons. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Dec 28 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-12-28 at 11:27 -0500, Andrei Alexandrescu wrote:
[=E2=80=A6]
  From the HSP (Holiday Spirit Police):

It is holiday, I have spirit, 44.55 to be precise. I shall go and imbibe :-)=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Dec 28 2012
prev sibling next sibling parent "Nicolas Sicard" <dransic gmail.com> writes:
On Friday, 28 December 2012 at 15:29:58 UTC, Jacob Carlborg wrote:
 On 2012-12-28 16:18, Russel Winder wrote:
 Is there a reason for using g++ to compile and link the C code 
 of DMD?

As far as I know it doesn't work with Clang. Did you have any other compiler in mind?

Actually it works with Clang (v4.5), albeit with many warnings. Just pass HOST_CC=clang++ to the makefile.
Dec 28 2012
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 28 December 2012 at 19:06:05 UTC, Walter Bright wrote:
 On 12/28/2012 7:51 AM, Russel Winder wrote:
 On Fri, 2012-12-28 at 16:30 +0100, David Nadlinger wrote:
 DMD is actually written in C++, Walter just chose file names
 ending in .c for some strange reason.

I can understand using C++ rather than C, but (sorry Walter) naming the files X.c is a f###### stupid idea. The standard name strategy is one of X.C, X.cc, or X.cpp, for very good reasons.

Yeah, the standard name is .C, or is it .cc, or is it .cpp, or is it .cxx (I've seen that "standard" one, too), and are headers .hxx or is the standard .hpp or whatever. Hell, I've even seen .c++ It's about the most non-standard "standard" I've ever encountered :-)

I guess the convention is "Anything that is clear as to language the file contains". ".cpp" and ".cxx" are both very good at that. ".cc" is less good, ".C" is even worse. All of them are better than ".c"
Dec 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, December 29, 2012 12:52:11 Marco Nembrini wrote:
 Nobody answered the important question: does it "break" pull requests?
 
 In my (limited) understanding git supports renames and pulls will be
 "broken" in the same way the are when there's a new commit on the
 original repo: people will just have to rebase their changes on it. I
 did some googling and found nobody complaining about this problem, so I
 assume there's some way to avoid it.

I would expect rebasing to fix it trivially so long as git mv was used rather than renaming the file with the OS' commands, but I don't know for sure. - Jonathan M Davis
Dec 28 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Saturday, 29 December 2012 at 02:11:03 UTC, Jonathan M Davis 
wrote:
 I would expect rebasing to fix it trivially so long as git mv 
 was used rather
 than renaming the file with the OS' commands, but I don't know 
 for sure.

 - Jonathan M Davis

IIRC, Git can figure out if a raw renamed file (a new file from git's perspective) is a rename of an old file if the contents are the same as a recently removed file above a certain threshold (70 percentish). Considering the contents of the files shouldn't change at all, I _think_ git should be able to figure out what's happened. No idea what'll happen to the pull requests, though.
Dec 28 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Saturday, 29 December 2012 at 03:27:38 UTC, Andrei 
Alexandrescu wrote:
 On 12/28/12 8:18 PM, Daniel Murphy wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in 
 message
 news:kbl3eh$2qe8$1 digitalmars.com...
 On 12/28/12 4:39 PM, Brad Roberts wrote:
 What impact does this have on the open pull requests?  If 
 it's going to
 suddenly break every one of them, then I think it's a 
 particularly bad
 idea.

There are dozens of open pull requests and if worse comes to worst people will agree to fix their requests because the request for changing extensions has enjoyed considerable popularity.
 The benefit is debatable and the cost is pretty annoying.

The benefit is we'll avoid resurrecting a debate that comes back and again. Technically there's no reason to move with the change, but right now we're wasting time and burning through karma. Making the change shows respect for the community and for working together in an environment that has few gratuitous idiosyncrasies. Let's do it. Thanks, Andrei

You want to screw up over a hundred open pull requests and destroy the commit history...

I used git mv, which to my understanding preserves commit history and makes pull requests easy to fix via a rebase: http://stackoverflow.com/questions/2641146/handling-file-renames-in-git Andrei

Dec 29 2012
prev sibling parent "Rob T" <rob ucora.com> writes:
On Saturday, 29 December 2012 at 03:27:38 UTC, Andrei 
Alexandrescu wrote:
 On 12/28/12 8:18 PM, Daniel Murphy wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in 
 message
 news:kbl3eh$2qe8$1 digitalmars.com...
 On 12/28/12 4:39 PM, Brad Roberts wrote:
 What impact does this have on the open pull requests?  If 
 it's going to
 suddenly break every one of them, then I think it's a 
 particularly bad
 idea.

There are dozens of open pull requests and if worse comes to worst people will agree to fix their requests because the request for changing extensions has enjoyed considerable popularity.
 The benefit is debatable and the cost is pretty annoying.

The benefit is we'll avoid resurrecting a debate that comes back and again. Technically there's no reason to move with the change, but right now we're wasting time and burning through karma. Making the change shows respect for the community and for working together in an environment that has few gratuitous idiosyncrasies. Let's do it. Thanks, Andrei

You want to screw up over a hundred open pull requests and destroy the commit history...

I used git mv, which to my understanding preserves commit history and makes pull requests easy to fix via a rebase: http://stackoverflow.com/questions/2641146/handling-file-renames-in-git Andrei

[bleep][bleep][bleep][bleep] it should *all* be .d at this point (last nail in C++ coffin please). Merry holidays everyone! --rt
Dec 29 2012