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