gcc 4.8.1 made it to Debian Sid

[H. S. Teoh]

On Wed, Jul 10, 2013 at 10:03:40AM +0200, Joseph Rushton Wakeling wrote:
> On 07/10/2013 02:07 AM, H. S. Teoh wrote:
> > I forked GDMD on github and took a first stab at D-ifying it:
> > 
> > 	https://github.com/quickfur/GDMD/tree/dport
> 
> Nice -- I'll try and have a play with that later :-)
> 
> First thing that strikes me -- and I know you're taking this from the
> original script -- what's with the references to dmd.conf?  GDC has no
> dmd.conf that I can recall (don't know whether it used to once upon a
> time), so this part of the script may even be dangerous if it winds up
> trying to find a config file that exists for dmd but not gdc/gdmd.

True. I suppose the idea was to make gdmd a possible drop-in replacement
for dmd, so it would behave the same way as dmd would from the user's
POV. But this may be dangerous if you have both dmd and gdc installed,
and gdmd picks up the wrong settings intended only for dmd.


> I'd have thought this could be deleted without problem.  If there _is_
> a conf script that needs using, it should be renamed to avoid
> potential clashes with DMD proper.

OK. I'll make the name an enum that can be changed later. At least,
it'll be better than hardcoding the filename. ;-)


> > The new code is in gdmd.d -- I haven't updated the Makefile to build
> > it yet, so you'll have to compile it by hand.  It can do very simple
> > compiles now (list of .d files -> executable), including compile
> > itself.  :) It can read dmd.conf and setup environment variables
> > accordingly, though I haven't actually tested whether it's really
> > doing what I think it's doing.  (Anybody up for writing unittests?
> > ;-))
> 
> I think that unittests can focus first on checking that gdmd input
> translates into correct gdc output (as in, what you get right now
> running gdmd --someoptions -vdmd).  That is, we can check each of the
> gdmd options singly and ensure they translate to correct gdc call
> strings.
> 
> I'm not sure to what extent we'd need to test combinations of gdmd
> flags as opposed to single flags.  There's also the whole bogeyman of
> contradictory flags (e.g. one turns on the optimizations, one turns
> them off...).

The problem I ran into when I thought about unittests was, the unittest
code basically has to do almost the same thing as what the code does
anyway, so it's not really *testing* the code per se, but testing your
ability to write the same code twice. I suppose we could test the more
tricky spots with explicit samples, though, like the parts parsed with
regexes.


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft
system vulnerabilities cannot touch Linux---is priceless. -- Frustrated
system administrator.