www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GDC options

reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
Hi,

ldc2 has the -unittest --main options to compile a file that has
unittests and no main so as to create a test executable. What causes
the same behaviour with gdc?

--=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
Mar 12 2017
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 12 Mar 2017 12:09:01 +0000
schrieb Russel Winder via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com>:

 Hi,
 
 ldc2 has the -unittest --main options to compile a file that has
 unittests and no main so as to create a test executable. What causes
 the same behaviour with gdc?
 
https://github.com/D-Programming-GDC/GDMD/tree/dport gdmd -unittest --main The unittest flag for GDC is -funittest but there's no flag to generate a main function. gdmd generates a temporary file with a main function to implement this. -- Johannes
Mar 12 2017
parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sun, 2017-03-12 at 16:38 +0100, Johannes Pfau via Digitalmars-d-
learn wrote:
=20
[=E2=80=A6]
=20
 https://github.com/D-Programming-GDC/GDMD/tree/dport
=20
 gdmd -unittest --main
=20
 The unittest flag for GDC is -funittest but there's no flag to
 generate
 a main function. gdmd generates a temporary file with a main function
 to implement this.
gdmd is not packaged with gdc so isn't a general solution. gdmd, like rdmd, should be packaged. awkward when using SCons and Meson. It is a shame that dmd and ldc do not just use the standard GCC option set. --=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
Mar 13 2017
parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Monday, 13 March 2017 at 11:06:53 UTC, Russel Winder wrote:
 It is a shame that dmd and ldc do not just use the standard GCC 
 option set.
Totally agreed. Moreover, funny stuff like "dmd -of<Target>" (instead of standard "-o <target>") breaks automatic Msys path conversion hack (the code translates Unix paths from the command line to Windows paths before the invocation of a non-msys program), which makes it impossible to use dmd under Msys without wrapping it first. pkg-config also is a real pain to use with dmd (the pkg-config's output needs to be post-processed so it has the form "-L-lstuff" instead of "-lstuff"). This is an issue, because it makes it very hard to use write portable makefiles for programs containing D code. Too bad, because the D code is actually platform-independent, and there's been a lot of work in Phobos to make it easy to write such code. D was designed to be binary compatible with the C ABI ; however, having a compiler whose command-line behaves so different from gcc makes it harder to actually work with existing C libs. This is actually the main reason why I almost exclusively use gdc: to have one Makefile, for all platforms, allowing native and cross-compilation with no platform-specific special cases.
Mar 21 2017
parent reply Matthias Klumpp <mak debian.org> writes:
On Wednesday, 22 March 2017 at 05:47:59 UTC, Sebastien Alaiwan 
wrote:
 On Monday, 13 March 2017 at 11:06:53 UTC, Russel Winder wrote:
 It is a shame that dmd and ldc do not just use the standard 
 GCC option set.
Totally agreed. Moreover, funny stuff like "dmd -of<Target>" (instead of standard "-o <target>") breaks automatic Msys path conversion hack (the code translates Unix paths from the command line to Windows paths before the invocation of a non-msys program), which makes it impossible to use dmd under Msys without wrapping it first. pkg-config also is a real pain to use with dmd (the pkg-config's output needs to be post-processed so it has the form "-L-lstuff" instead of "-lstuff"). This is an issue, because it makes it very hard to use write portable makefiles for programs containing D code. Too bad, because the D code is actually platform-independent, and there's been a lot of work in Phobos to make it easy to write such code. D was designed to be binary compatible with the C ABI ; however, having a compiler whose command-line behaves so different from gcc makes it harder to actually work with existing C libs. This is actually the main reason why I almost exclusively use gdc: to have one Makefile, for all platforms, allowing native and cross-compilation with no platform-specific special cases.
This is why most of my work in Meson to get D supported is adding weird hacks to translate compiler flags between GNU <-> non-GNU <-> DMD. It sucks quite badly, and every now and then I hit a weird corner case where things break. For example: https://github.com/mesonbuild/meson/commit/d9cabe9f0ca6fb06808c1d5cf5206a7c5158517e Would be amazing if all D compilers would support the GCC flags, like Clang does for C - that would help in removing a lot of hacks (and making Makefiles which work with all compilers). The reason for not using a dmd wrapper is that one might want to use flags specific to a certain compiler.
Mar 22 2017
parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Wednesday, 22 March 2017 at 13:42:21 UTC, Matthias Klumpp 
wrote:
 This is why most of my work in Meson to get D supported is 
 adding weird hacks to translate compiler flags between GNU <-> 
 non-GNU <-> DMD. It sucks quite badly, and every now and then I 
 hit a weird corner case where things break.
 For example: 
 https://github.com/mesonbuild/meson/commit/d9cabe9f0ca6fb06808c1d5cf5206a7c5158517e
One day, we'll have to decide if we should align build systems on compilers, or the other way around. In the meantime, could everyone please align on clang and gcc ? :-)
Jun 05 2017
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 5 June 2017 at 18:22:31 UTC, Sebastien Alaiwan wrote:
 On Wednesday, 22 March 2017 at 13:42:21 UTC, Matthias Klumpp 
 wrote:
 This is why most of my work in Meson to get D supported is 
 adding weird hacks to translate compiler flags between GNU <-> 
 non-GNU <-> DMD. It sucks quite badly, and every now and then 
 I hit a weird corner case where things break.
 For example: 
 https://github.com/mesonbuild/meson/commit/d9cabe9f0ca6fb06808c1d5cf5206a7c5158517e
One day, we'll have to decide if we should align build systems on compilers, or the other way around. In the meantime, could everyone please align on clang and gcc ? :-)
We're getting there, slowly. Although its a tight balance between dmd compatibility and gcc/clang compatibility, see -[f]unittest. https://github.com/ldc-developers/ldc/pull/2149
Jun 05 2017