www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - bud and lib paths

reply torhu <no spam.invalid> writes:
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.
Oct 15 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
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
Oct 15 2007
parent reply torhu <no spam.invalid> writes:
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.
Oct 16 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
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
Oct 16 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Oct 16 2007
parent Derek Parnell <derek nomail.afraid.org> writes:
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
Oct 16 2007