I'm wondering if anyone has got any experience with this problem.  I'm trying to build a wxD sample outside of wxD's installation directory, to see if I can get it working.  I've left the wxWidget lib files in wxWidget's installation directory instead of copying them into dm/lib. So I need optlink to find them somehow. I've tried this:

bud -full minimal -gui -LIBPATH=c:\prog\wxWidgets-2.6.4\lib\dmc_lib wxbase26d.lib

But I get "Warning 2: File Not Found wxbase26d.lib".  This isn't the complete command line needed to build the example, but it shows the same error.  I've also tried setting the LIB environment variable, but I guess bud doesn't pass it on when running optlink.  Anyone else seen this problem with bud?  Is there another way to achieve the same thing?

Rebuild's -S (works like -LIBPATH) option works just fine, but needs 46 seconds to build the minimal example, compared to 7 with bud.  Not a great option.  Maybe I'll go with copying the files instead.

On Tue, 16 Oct 2007 02:53:03 +0200, torhu wrote:

> I'm wondering if anyone has got any experience with this problem.  I'm trying to build a wxD sample outside of wxD's installation directory, to see if I can get it working.  I've left the wxWidget lib files in wxWidget's installation directory instead of copying them into dm/lib. So I need optlink to find them somehow. I've tried this:
> 
> bud -full minimal -gui -LIBPATH=c:\prog\wxWidgets-2.6.4\lib\dmc_lib wxbase26d.lib

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.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
16/10/2007 11:25:38 AM

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.

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.

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

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
17/10/2007 2:55:15 PM

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

On Wed, 17 Oct 2007 14:11:13 +0900, Bill Baxter wrote:

> 
> 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?

Not really. The problem is that these constant literals are defined as 'const char' and not 'invariant char'. This below illustrates the problem...


 invariant char[1] IS = "/";
 const     char[1] CS = "/";

 void main()
 {
    string[] x;

    x ~= IS; // Okay
    x ~= CS; // Fails
 }

To get around this I need to ...

   x ~= CS.idup;


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
17/10/2007 4:17:40 PM