> -----Original Message-----
> From: Nils Hensel
> Sent: Monday, 25 April 2005 9:04 AM
> To: ddparnell (a.t) bigpond (d.o.t) com
> Subject: Build problems
> 
> Hello Derek,
> 
> here are the files you requested. The first run was with the unmodified wxdefs and the second one is after modification. But you will notice this anyhow when you take a look at them.
> 

Okay, I think I can see the mistake. It seems that all the .obj files, except for wx\wx.obj is up to date, but Build is not recognizing that fact, so doesn't recompile wx\wx.d.  You should get it to work ok with the '-full' switch, which forces a full recompile of all sources. Once this gets it into sync again, then build should work as advertised. In the meantime, I'll fix the bug for the next release.

Thanks for helping me find this mistake of mine.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
25/04/2005 2:17:22 PM

On Sun, 24 Apr 2005 20:31:00 +0200, Nils Hensel wrote:

> Derek Parnell schrieb:
>> Well so am I! Look, I want it to handle that sort of situation and so far my testing says it can. Can I have a look at your 'wxdefs' file to see if I can replicate the problem at my end - so I can improve Build if it needs it.

I finally managed to replicate the messages you are getting. And it seems that the mistake is your area. Build is working okay-ish. It could give a better message, but for now its doing its job okay.

It seems that you have inside HexMonster.d a line that reads something like ...

  import wx.wd;

but the file "wx\wx.d" does not exist!

The mistake, if you like to call it that, is that Build wrongly assumes that wx\wx.d is up-to-date because wx\wx.d *and* wx\wx.obj both don't exist. So Build then incorrectly adds wx\wx.obj to the command line. What it should do is issue a message the requested module "wx.wx" cannot be found, instead of letting DMD find that out.

The problem goes away once I create wx\wx.d

-- 
Derek Parnell
Melbourne, Australia
25/04/2005 4:06:40 PM

On Mon, 25 Apr 2005 16:12:49 +1000, Derek Parnell wrote:

> I finally managed to replicate the messages you are getting. And it seems that the mistake is your area. Build is working okay-ish. It could give a better message, but for now its doing its job okay.

Weird! Now I can't replicate the errors again. While testing my changes, I tried to get the same message you were getting, and now I can't do it.  So I'm once again uncertain as to what's causing the messages you get. Oh well, back to analyzing...

-- 
Derek Parnell
Melbourne, Australia
25/04/2005 5:01:08 PM

TechnoZeus wrote:

> That's exactly what was happening in my case,
> and I did find that I could work around it...
> but like you Anders pointed out,
> it's a bit tedious.

To be perfectly clear, I just that it is more work
to use a library module made in D from D than what
it is in e.g. the Python or Java languages/runtimes...

But if that library is external to those (Python/Java),
then the "hassle" here is about the same in all of them.
(Usually done by loading a shared library with the code)


It's really not very different from how you link C/C++.
And for the simple D stuff you can usually throw all .d
files on "dmd" at once - and the rest can use a library ?

Which reminds me that I should give Build 2.0 a whirl...

--anders

PS. Short porting tip:

If a C header file that you translate says something like:

extern void foo(void);
#define bar foo

Then you can use "alias" in D:

extern(C):
void foo();
alias foo bar;

If you instead use a wrapper:

extern(C):
void foo();
void bar() { foo(); }

You get new "bar" object code, and thus must link to this D code later ?
(for the simple alias, linking with the translated C library is enough)

Sometimes, you need the wrappers though... Either the #define above
adds a few parameters, or it's a complex macro "function" in itself.

"Anders F Björklund" <afb@algonet.se> wrote in message news:d4i6ak$17ni$1@digitaldaemon.com...
> TechnoZeus wrote:
>
> > That's exactly what was happening in my case,
> > and I did find that I could work around it...
> > but like you Anders pointed out,
> > it's a bit tedious.
>
> To be perfectly clear, I just that it is more work
> to use a library module made in D from D than what
> it is in e.g. the Python or Java languages/runtimes...
>
> But if that library is external to those (Python/Java),
> then the "hassle" here is about the same in all of them.
> (Usually done by loading a shared library with the code)
>
>
> It's really not very different from how you link C/C++.
> And for the simple D stuff you can usually throw all .d
> files on "dmd" at once - and the rest can use a library ?
>
> Which reminds me that I should give Build 2.0 a whirl...
>
> --anders
>
> PS. Short porting tip:
>
> If a C header file that you translate says something like:
>
> extern void foo(void);
> #define bar foo
>
> Then you can use "alias" in D:
>
> extern(C):
> void foo();
> alias foo bar;
>
> If you instead use a wrapper:
>
> extern(C):
> void foo();
> void bar() { foo(); }
>
> You get new "bar" object code, and thus must link to this D code later ? (for the simple alias, linking with the translated C library is enough)
>
> Sometimes, you need the wrappers though... Either the #define above adds a few parameters, or it's a complex macro "function" in itself.

Thanks.  Not working with any C though... but still, it was in interesting explanation.  :)

TZ

Derek Parnell schrieb:
> It seems that you have inside HexMonster.d a line that reads something like
> ...
> 
>   import wx.wd;

That is correct.

> but the file "wx\wx.d" does not exist! 

Well, it does exist along the include path. I copied the wx directory to c:\dmd\src\ because that directory was already in my include path.

in my sc.ini it reads:

DFLAGS="-I%@P%\..\src\phobos";C:\MySource\D\dfl;C:\dmd\src;

which works fine with dmd. Perhaps build should check DFLAGS and look for missing *.d files there?


Nils

On Mon, 25 Apr 2005 12:19:01 +0200, Nils Hensel wrote:

> Derek Parnell schrieb:
>> It seems that you have inside HexMonster.d a line that reads something like ...
>> 
>>   import wx.wd;
> 
> That is correct.
> 
>> but the file "wx\wx.d" does not exist!
> 
> Well, it does exist along the include path. I copied the wx directory to c:\dmd\src\ because that directory was already in my include path.
> 
> in my sc.ini it reads:
> 
> DFLAGS="-I%@P%\..\src\phobos";C:\MySource\D\dfl;C:\dmd\src;
> 
> which works fine with dmd. Perhaps build should check DFLAGS and look for missing *.d files there?
> 

Bingo! Build already does use the DFLAGS entry in the sc.ini file. However, it obviously parses it differently to DMD. Build only saw the -I flag from the quoted section. The stuff out of the quotes it ignored. Had you written

 DFLAGS="-I%@P%\..\src\phobos;C:\MySource\D\dfl;C:\dmd\src;"

it would have added all three paths and not just the first one.

I should have picked this up earlier as the clue is in the -V display.

> Line 6: DFLAGS="-Ic:\dmd\bin\..\src\phobos";C:\MySource\D\dfl;C:\dmd\src; added root from config file c:\dmd\src\phobos\

But it should have also had
> added root from config file C:\MySource\D\dfl
> added root from config file c:\dmd\src\

I'll fix this bug tonight.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
25/04/2005 9:08:45 PM

Derek Parnell schrieb:
> Bingo! Build already does use the DFLAGS entry in the sc.ini file. However,
> it obviously parses it differently to DMD. Build only saw the -I flag from
> the quoted section. The stuff out of the quotes it ignored. Had you written 
> 
>  DFLAGS="-I%@P%\..\src\phobos;C:\MySource\D\dfl;C:\dmd\src;"
> 
> it would have added all three paths and not just the first one. I should have picked this up earlier as the clue is in the -V display.
> I'll fix this bug tonight.

Great! I'm glad I could help catching this bug and am looking forward to using build in the future.

Greetz,
Nils