On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
> As noted in my earlier email on the other list, I too got this problem. Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is no such thing in the 1.067 and 2.052 distributions.  So the "out of the box" configuration does seem to be "broken".

And as I said in my response to your other message, the proper dmd.conf file _is_ in the distributed zip file. So, unless you're dealing with the deb or rpm, and they're broken, and I don't know why you wouldn't be seeing a new dmd.conf with the 2.052 release. But I don't know what the state of the rpm or deb is. I just always use the zip file, which is very simple.

- Jonathan M Davis

Jonathan,

On Fri, 2011-02-18 at 17:28 -0800, Jonathan M Davis wrote:
> On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
> > As noted in my earlier email on the other list, I too got this problem. Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is no such thing in the 1.067 and 2.052 distributions.  So the "out of the box" configuration does seem to be "broken".
> 
> And as I said in my response to your other message, the proper dmd.conf file _is_ in the distributed zip file. So, unless you're dealing with the deb or rpm, and they're broken, and I don't know why you wouldn't be seeing a new dmd.conf with the 2.052 release. But I don't know what the state of the rpm or deb is. I just always use the zip file, which is very simple.

I was too tired last evening to think this through properly, my apologies.  Hopefully I am now more with it.

I made a single character typing error in my diff last evening that was critical to my statement that the two conf files were the same. Correcting that, the two are clearly not the same, and I do indeed have a conf file with lib32 and lib64 in the environment line, exactly as you assured me.  My fault for doubting, apologies.

Of course this now raises the issue that if I have the right configuration, why is the library necessary for correct linking of std.date and std.datetime not being found "out of the box".  I can see the -L-lrt at the end of the line in the dmd.conf file.  I can see:

/usr/lib/librt.a
/usr/lib/librt.so
/usr/lib32/librt.a
/usr/lib32/librt.so

are present and correct on my machine.  OK so it is blindingly obvious: I am using SCons, which builds its own dmd/gcc sequence of calls instead of just using dmd as a driver for hte whole compile and link.  The crucial point is that it separates calling dmd from calling gcc.  Thus the real question is then: should the SCons D tool be reading the dmd.conf, editing the first -L out since that is to get the option from the dmd to the gcc when dmd is the driver.  Alternatively do I just replicate the knowledge in the dmd.conf file?

-- 
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@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday 19 February 2011 04:39:21 Russel Winder wrote:
> Jonathan,
> 
> On Fri, 2011-02-18 at 17:28 -0800, Jonathan M Davis wrote:
> > On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
> > > As noted in my earlier email on the other list, I too got this problem. Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is no such thing in the 1.067 and 2.052 distributions.  So the "out of the box" configuration does seem to be "broken".
> > 
> > And as I said in my response to your other message, the proper dmd.conf file _is_ in the distributed zip file. So, unless you're dealing with the deb or rpm, and they're broken, and I don't know why you wouldn't be seeing a new dmd.conf with the 2.052 release. But I don't know what the state of the rpm or deb is. I just always use the zip file, which is very simple.
> 
> I was too tired last evening to think this through properly, my apologies.  Hopefully I am now more with it.
> 
> I made a single character typing error in my diff last evening that was critical to my statement that the two conf files were the same. Correcting that, the two are clearly not the same, and I do indeed have a conf file with lib32 and lib64 in the environment line, exactly as you assured me.  My fault for doubting, apologies.
> 
> Of course this now raises the issue that if I have the right configuration, why is the library necessary for correct linking of std.date and std.datetime not being found "out of the box".  I can see the -L-lrt at the end of the line in the dmd.conf file.  I can see:
> 
> /usr/lib/librt.a
> /usr/lib/librt.so
> /usr/lib32/librt.a
> /usr/lib32/librt.so
> 
> are present and correct on my machine.  OK so it is blindingly obvious: I am using SCons, which builds its own dmd/gcc sequence of calls instead of just using dmd as a driver for hte whole compile and link.  The crucial point is that it separates calling dmd from calling gcc.  Thus the real question is then: should the SCons D tool be reading the dmd.conf, editing the first -L out since that is to get the option from the dmd to the gcc when dmd is the driver.  Alternatively do I just replicate the knowledge in the dmd.conf file?

I don't know anything about SCons. However, you _can_ use dmd to link if you want to (though that doesn't always work, since not all linker flags make it through safely; e.g., -L-static), so you shouldn't normally actually need to use gcc, even if you're doing incremental builds.

Now, if you need to use gcc for whatever reason, then you're going to need to either duplicate the flags in dmd.conf or parse it out. If it's just for you, then duplicating it would make sense. However, since dmd.conf is intended to be able to be tweaked by whoever is using it (adjusting where the libraries, adding extra flags, whatever), if the SCons D tool is supposed to know what flags to use, and it's supposed to work on anyone's computer, then it's going to need to parse out dmd.conf. Otherwise, it won't be correct on the machine of anyone who doesn't use the default configuration.

But as I said, I know nothing about SCons, so I don't know what the best way to handle it is.

- Jonathan M Davis

On Sat, 2011-02-19 at 04:55 -0800, Jonathan M Davis wrote: [ . . . ]
> I don't know anything about SCons. However, you _can_ use dmd to link if you want to (though that doesn't always work, since not all linker flags make it through safely; e.g., -L-static), so you shouldn't normally actually need to use gcc, even if you're doing incremental builds.

I'll have a play with using DMD as the driver for all stages.

> Now, if you need to use gcc for whatever reason, then you're going to need to either duplicate the flags in dmd.conf or parse it out. If it's just for you, then duplicating it would make sense. However, since dmd.conf is intended to be able to be tweaked by whoever is using it (adjusting where the libraries, adding extra flags, whatever), if the SCons D tool is supposed to know what flags to use, and it's supposed to work on anyone's computer, then it's going to need to parse out dmd.conf. Otherwise, it won't be correct on the machine of anyone who doesn't use the default configuration.
> 
> But as I said, I know nothing about SCons, so I don't know what the best way to handle it is.

Actually I think your summary works very well :-)

I will look to replace all the hardwired replication of information with a simple parse of the configuration file.  The hard question is: where is the configuration file?

The problem I have here is that I have 64-bit Ubuntu, 64-bit Ubuntu, 64-bit Mac OS X and 32-bit Mac OS X but nothing else.which means I can only really develop 50% of the plugin.  I really need a Windows person to work with to co-develop this.

-- 
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@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 2011-02-19 at 20:07 +0000, Russel Winder wrote:
[ . . . ]
> The problem I have here is that I have 64-bit Ubuntu, 64-bit Ubuntu,

s/Ubuntu/Debian/

-- 
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@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday 19 February 2011 12:07:40 Russel Winder wrote:
> On Sat, 2011-02-19 at 04:55 -0800, Jonathan M Davis wrote: [ . . . ]
> 
> > I don't know anything about SCons. However, you _can_ use dmd to link if you want to (though that doesn't always work, since not all linker flags make it through safely; e.g., -L-static), so you shouldn't normally actually need to use gcc, even if you're doing incremental builds.
> 
> I'll have a play with using DMD as the driver for all stages.
> 
> > Now, if you need to use gcc for whatever reason, then you're going to need to either duplicate the flags in dmd.conf or parse it out. If it's just for you, then duplicating it would make sense. However, since dmd.conf is intended to be able to be tweaked by whoever is using it (adjusting where the libraries, adding extra flags, whatever), if the SCons D tool is supposed to know what flags to use, and it's supposed to work on anyone's computer, then it's going to need to parse out dmd.conf. Otherwise, it won't be correct on the machine of anyone who doesn't use the default configuration.
> > 
> > But as I said, I know nothing about SCons, so I don't know what the best way to handle it is.
> 
> Actually I think your summary works very well :-)
> 
> I will look to replace all the hardwired replication of information with a simple parse of the configuration file.  The hard question is: where is the configuration file?

Well, the dmd page very explicitly lays out the various places that the dmd.conf file (or sc.ini file on Windows) will be looked for and in what order (since there could also be a dmd.conf in multiple places, and it needs to use the same one that dmd would).

> The problem I have here is that I have 64-bit Ubuntu, 64-bit Ubuntu, 64-bit Mac OS X and 32-bit Mac OS X but nothing else.which means I can only really develop 50% of the plugin.  I really need a Windows person to work with to co-develop this.

I know the feeling. At least you have Mac OS X. Wine could help you fill in the gaps though.

- Jonathan M Davis

== Quote from Jonathan M Davis (jmdavisProg@gmx.com)'s article
> On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
> > As noted in my earlier email on the other list, I too got this problem. Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is no such thing in the 1.067 and 2.052 distributions.  So the "out of the box" configuration does seem to be "broken".
> And as I said in my response to your other message, the proper dmd.conf file _is_
> in the distributed zip file. So, unless you're dealing with the deb or rpm, and
> they're broken, and I don't know why you wouldn't be seeing a new dmd.conf with
> the 2.052 release. But I don't know what the state of the rpm or deb is. I just
> always use the zip file, which is very simple.
> - Jonathan M Davis

Ok, I can fix the dmd.conf. Who does manage the RPM packaging? And how can I get a hold of them?

On Monday 21 February 2011 08:40:38 Kai Meyer wrote:
> == Quote from Jonathan M Davis (jmdavisProg@gmx.com)'s article
> 
> > On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
> > > As noted in my earlier email on the other list, I too got this problem. Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is no such thing in the 1.067 and 2.052 distributions.  So the "out of the box" configuration does seem to be "broken".
> > 
> > And as I said in my response to your other message, the proper dmd.conf
> > file _is_ in the distributed zip file. So, unless you're dealing with
> > the deb or rpm, and they're broken, and I don't know why you wouldn't be
> > seeing a new dmd.conf with the 2.052 release. But I don't know what the
> > state of the rpm or deb is. I just always use the zip file, which is
> > very simple.
> > - Jonathan M Davis
> 
> Ok, I can fix the dmd.conf. Who does manage the RPM packaging? And how can I get a hold of them?

I'm not sure who deals with the RPM stuff (though looking at the download on the site, the rpm hasn't been updated 2.052 - it's still on 2.051). If it's broken, post on the "dmd 1.067 and 2.052 release" thread in D.announce, since that's where people are generally looking for info on the release. If you haven't registered with the announce list, then you can just start a thread on it in the main D list. That's the place that the most people will notice and where you're most likely to get the attention of whoever it is needs to know (which may be Walter, but I don't know).

However, I _would_ point out that it's extremely easy to just the zip file. I've never bothered with the rpm, personally. So, while the rpm should definitely should be fixed, if all you're really looking to do is have a working dmd, using the zip is likely a good option. You just download it and unzip it to wherever you want it (e.g. your home folder) and then add the path to the linux/bin folder within it (e.g. ~/dmd2/linux/bin) to your PATH variable (presumably in your .bashrc), and it then it'll work just fine. It'll grab phobos from the right place and the dmd.conf will be correct. Every time that a new version is released, you just replace the dmd2 folder with the newly unzipped version, and it works.

- Jonathan M Davis