bud and lib paths

Bill Baxter dnewsgroup at billbaxter.com
Tue Oct 16 22:11:13 PDT 2007


Derek Parnell wrote:
> On Tue, 16 Oct 2007 17:18:13 +0200, torhu wrote:
> 
>> Derek Parnell wrote:
>>   > You have found a bug in Bud. The problem is not the library path as 
>> such,
>>> but it doesn't recognize the library name correctly. I'll work on this
>>> tonight.
>>>
>> Thanks!  Will there be a new release of bud soon?  Bud and rebuild have 
>> different weak spots, but for us Windows/DMD users, bud seems to still 
>> be the best option.  DSSS and Rebuild seem to be tailored to linux and GDC.
>>
>> I also appreciate bud being largely indifferent to which version of the 
>> D language it parses, while rebuild's use of the dmd front-end makes it 
>> choke on new D syntax. Every annoyance counts.
> 
> Unfortunately, 2.006 has broken a whole lot of code. I've being going
> through the fix ups all day and I guess I'm about half done. The use of
> ".idup" is becoming very pervasive! The main culprit is trying to append
> std.path.sep and similar "literals" to 'string' variables.

Eek, you mean this
    char[] x;
    x ~= std.path.sep;

Has to be written
    char[] x;
    x ~= std.path.sep.idup;

??
That seems like a bug.  You're not modifying sep at all.  Maybe the 
built-in "opCatAssign" is not declared as taking const like it should?

> Then I've got to get it V1 compatible again so that I suspect will also
> bring a new set of nightmares. 

<psst **preprocessor** pssst>

What was that? Did you hear something just now? :-)

--bb


More information about the Digitalmars-d-learn mailing list