www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - Another dwt-win / dmd / dsss build problem

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
I'm getting tons of warnings like this from the linker trying to compile 
the controlexample:
---
...
  Warning 148: USE16/USE32 Mismatch : _DATA
f:\usr\pkg\d\dsss\lib\\DD-dwt.lib(ImageLoaderEvent)  Offset 1EA7CH 
Record Type 0099
...
---
and some of these:
---
  Error 42: Symbol Undefined __memset64
f:\usr\pkg\d\dsss\lib\\DD-dwt.lib(LEDataInputStream)
  Error 42: Symbol Undefined 
_D5tango4core9Exception20ArrayBoundsException7__ClassZ
---
and then these:
---
...
(NAPPLOAD)
  Error 41: Unrecognized FIXUPP Type at Relative 001DDH  from
  Segment LOADER___SLRLOAD
  FRAME  = Frame of TARGET 00000H
  TARGET = Segment LOADER___SLRLOAD 04000H
  FIXUPP Type = 16-bit Offset
...
---
and then finally:
---
--- errorlevel 172
Command f:\usr\pkg\d\dsss\bin\rebuild.exe returned with code -1, aborting.
Error: Command failed, aborting.
---

Any idea what I'm doing wrong?

Here's the dsss.conf I made for the example:

---
[ControlExample.d]
debugflags +=-g -debug
buildflags +=-J.
buildflags +=-I../..
buildflags +=-S../../../dwt-win/lib
buildflags +=-L/SUBSYSTEM:windows:5
---


--bb
Feb 13 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Bill Baxter wrote:

 I'm getting tons of warnings like this from the linker trying to compile 
 the controlexample:
 ---
 ...
  Warning 148: USE16/USE32 Mismatch : _DATA
 f:\usr\pkg\d\dsss\lib\\DD-dwt.lib(ImageLoaderEvent)  Offset 1EA7CH 
 Record Type 0099
 ...
 ---
 and some of these:
 ---
  Error 42: Symbol Undefined __memset64
 f:\usr\pkg\d\dsss\lib\\DD-dwt.lib(LEDataInputStream)
  Error 42: Symbol Undefined 
 _D5tango4core9Exception20ArrayBoundsException7__ClassZ
 ---
 and then these:
 ---
 ...
 (NAPPLOAD)
  Error 41: Unrecognized FIXUPP Type at Relative 001DDH  from
  Segment LOADER___SLRLOAD
  FRAME  = Frame of TARGET 00000H
  TARGET = Segment LOADER___SLRLOAD 04000H
  FIXUPP Type = 16-bit Offset
 ...
 ---
 and then finally:
 ---
 --- errorlevel 172
 Command f:\usr\pkg\d\dsss\bin\rebuild.exe returned with code -1, aborting.
 Error: Command failed, aborting.
 ---
 
 Any idea what I'm doing wrong?
 
 Here's the dsss.conf I made for the example:
 
 ---
 [ControlExample.d]
 debugflags +=-g -debug
 buildflags +=-J.
 buildflags +=-I../..
 buildflags +=-S../../../dwt-win/lib
 buildflags +=-L/SUBSYSTEM:windows:5
 ---
 
 
 --bb



I cannot reproduce this on my system.  My Tango svn revision is 3157.

Just out of curiosity, why do you activate the -J switch for dmd?  It 
isn't necessary (unless you've customized something).

At any rate, it does look like the age-old optlink is going berserk.  It 
would be nice if we could get things working using an updated gdc (mingw).

-JJR
Feb 13 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
John Reimer wrote:

 Bill Baxter wrote:

 I'm getting tons of warnings like this from the linker trying to 
 compile the controlexample:
 ---
 ...
  Warning 148: USE16/USE32 Mismatch : _DATA
 f:\usr\pkg\d\dsss\lib\\DD-dwt.lib(ImageLoaderEvent)  Offset 1EA7CH 
 Record Type 0099
 ...
 ---
 and some of these:
 ---
  Error 42: Symbol Undefined __memset64
 f:\usr\pkg\d\dsss\lib\\DD-dwt.lib(LEDataInputStream)
  Error 42: Symbol Undefined 
 _D5tango4core9Exception20ArrayBoundsException7__ClassZ
 ---
 and then these:
 ---
 ...
 (NAPPLOAD)
  Error 41: Unrecognized FIXUPP Type at Relative 001DDH  from
  Segment LOADER___SLRLOAD
  FRAME  = Frame of TARGET 00000H
  TARGET = Segment LOADER___SLRLOAD 04000H
  FIXUPP Type = 16-bit Offset
 ...
 ---
 and then finally:
 ---
 --- errorlevel 172
 Command f:\usr\pkg\d\dsss\bin\rebuild.exe returned with code -1, 
 aborting.
 Error: Command failed, aborting.
 ---

 Any idea what I'm doing wrong?

 Here's the dsss.conf I made for the example:

 ---
 [ControlExample.d]
 debugflags +=-g -debug
 buildflags +=-J.
 buildflags +=-I../..
 buildflags +=-S../../../dwt-win/lib
 buildflags +=-L/SUBSYSTEM:windows:5
 ---


 --bb


 
 
 I cannot reproduce this on my system.  My Tango svn revision is 3157.
 
 Just out of curiosity, why do you activate the -J switch for dmd?  It 
 isn't necessary (unless you've customized something).


Why? Because ControlExample.d contains many of these:

         cast(byte[]) import( "closedFolder.gif" ),



 At any rate, it does look like the age-old optlink is going berserk.  It 
 would be nice if we could get things working using an updated gdc (mingw).


I wouldn't use it unless it consistently tracked DMD features and bug 
fixes with a lag of no more than 3 days.

--bb
Feb 13 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Bill Baxter wrote:

 John Reimer wrote:

 I cannot reproduce this on my system.  My Tango svn revision is 3157.

 Just out of curiosity, why do you activate the -J switch for dmd?  It 
 isn't necessary (unless you've customized something).


 
 Why? Because ControlExample.d contains many of these:
 
         cast(byte[]) import( "closedFolder.gif" ),
 
 



Oops... My apologies! I haven't even looked in ControlExample.d yet. 
That'll teach me for putting my foot in my mouth.  I had a peek in 
dsss.conf, and apparently I missed seeing the -J switch.  Ironically 
enough, the images still aren't working in my current build of the 
controlexample binary.  So much for that.




 At any rate, it does look like the age-old optlink is going berserk.  
 It would be nice if we could get things working using an updated gdc 
 (mingw).


 
 I wouldn't use it unless it consistently tracked DMD features and bug 
 fixes with a lag of no more than 3 days.
 
 --bb



Okay.  Not likely to happen.  Unfortunately, gdc is currently the only 
way anything will ever get ported to other platfroms besides linux and 
win32.  Because of this, I want to see things working with gdc at some 
point, though doing so may be more of a handicap than it's worth.

-JJR
Feb 13 2008
parent reply John Reimer <terminal.node gmail.com> writes:
John Reimer wrote:


 
 
 Oops... My apologies! I haven't even looked in ControlExample.d yet. 
 That'll teach me for putting my foot in my mouth.  I had a peek in 
 dsss.conf, and apparently I missed seeing the -J switch.  Ironically 
 enough, the images still aren't working in my current build of the 
 controlexample binary.  So much for that.
 
 


Correction.  I have actually examined controlexample, but not enough to 
notice the imports. :P
Feb 13 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
John Reimer wrote:

 John Reimer wrote:
 

 Oops... My apologies! I haven't even looked in ControlExample.d yet. 
 That'll teach me for putting my foot in my mouth.  I had a peek in 
 dsss.conf, and apparently I missed seeing the -J switch.  Ironically 
 enough, the images still aren't working in my current build of the 
 controlexample binary.  So much for that.


 
 Correction.  I have actually examined controlexample, but not enough to 
 notice the imports. :P



I think I'm just going to give up on dwt-win for the time being, and 
come back in a month or so hoping more of the kinks will have been 
worked out by then.

Thanks for your help.

--bb
Feb 13 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Bill Baxter wrote:

 John Reimer wrote:

 John Reimer wrote:


 Oops... My apologies! I haven't even looked in ControlExample.d yet. 
 That'll teach me for putting my foot in my mouth.  I had a peek in 
 dsss.conf, and apparently I missed seeing the -J switch.  Ironically 
 enough, the images still aren't working in my current build of the 
 controlexample binary.  So much for that.


 Correction.  I have actually examined controlexample, but not enough 
 to notice the imports. :P


 
 
 I think I'm just going to give up on dwt-win for the time being, and 
 come back in a month or so hoping more of the kinks will have been 
 worked out by then.
 
 Thanks for your help.
 
 --bb



Fair enough.
Feb 13 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
John Reimer wrote:

 Bill Baxter wrote:

 John Reimer wrote:

 John Reimer wrote:


 Oops... My apologies! I haven't even looked in ControlExample.d yet. 
 That'll teach me for putting my foot in my mouth.  I had a peek in 
 dsss.conf, and apparently I missed seeing the -J switch.  Ironically 
 enough, the images still aren't working in my current build of the 
 controlexample binary.  So much for that.


 Correction.  I have actually examined controlexample, but not enough 
 to notice the imports. :P



 I think I'm just going to give up on dwt-win for the time being, and 
 come back in a month or so hoping more of the kinks will have been 
 worked out by then.

 Thanks for your help.

 --bb


 
 
 Fair enough.


Aw crap.  I figured it out.  Damn DSSS.
I was adding a library path like:
    buildflags +=-S../../../dwt-win/lib

DSSS+dmd chokes on forward slashes in library paths.  I think I knew 
this, but had forgotten.  There was probably a tell-tale error about 
that that would have clued me in but I got so many other errors that the 
first error line was out of my history buffer.

--bb
Feb 13 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:

 John Reimer wrote:

 Bill Baxter wrote:

 John Reimer wrote:

 John Reimer wrote:


 Oops... My apologies! I haven't even looked in ControlExample.d 
 yet. That'll teach me for putting my foot in my mouth.  I had a 
 peek in dsss.conf, and apparently I missed seeing the -J switch.  
 Ironically enough, the images still aren't working in my current 
 build of the controlexample binary.  So much for that.


 Correction.  I have actually examined controlexample, but not enough 
 to notice the imports. :P



 I think I'm just going to give up on dwt-win for the time being, and 
 come back in a month or so hoping more of the kinks will have been 
 worked out by then.

 Thanks for your help.

 --bb



 Fair enough.


 
 Aw crap.  I figured it out.  Damn DSSS.
 I was adding a library path like:
    buildflags +=-S../../../dwt-win/lib
 
 DSSS+dmd chokes on forward slashes in library paths.  I think I knew 
 this, but had forgotten.  There was probably a tell-tale error about 
 that that would have clued me in but I got so many other errors that the 
 first error line was out of my history buffer.
 
 --bb
 


...And other linker errors came from not having this in dsss.conf
    buildflags += -version=CONTROL_EXAMPLE_MAIN


For the record, my working dsss.conf for dwt-win build of the 
controlexample is:

-------
[ControlExample.d]
noinstall
buildflags += -version=CONTROL_EXAMPLE_MAIN
debugflags +=-g -debug
buildflags +=-J.
buildflags +=-I../..
version(Windows) {
buildflags +=-S..\..\..\dwt-win\lib
buildflags +=-L/SUBSYSTEM:windows:5
}
-------

Most of this pain of mine would have been avoided if there were working 
dsss.conf files included with the dwt-samples project.

Anyway, any idea why those images on buttons and such don't show up in 
the controlexample?

--bb
Feb 13 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:

 Most of this pain of mine would have been avoided if there were working 
 dsss.conf files included with the dwt-samples project.


And now I see that there is a dsss.conf at the top-level that covers all 
the subprojects.  Dangit!

--bb
Feb 13 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Bill Baxter wrote:

 Bill Baxter wrote:

 Most of this pain of mine would have been avoided if there were 
 working dsss.conf files included with the dwt-samples project.


 
 And now I see that there is a dsss.conf at the top-level that covers all 
 the subprojects.  Dangit!
 
 --bb



I was confused as to why you were using your own dsss.conf... But, 
anyway, glad you figured it out.

Now I recall I had the same problem with dsss and forward slashes.  The 
strange thing is that dsss reads forward slashes in the dsss.conf file 
but not on the command line :P.  This is an example of why 
troubleshooting gets confusing with the problems layered from several 
technologies. I wish it were easier.

About the images in the buttons... Are they missing on yours too?  Are 
you using Windows XP?  I haven't been able to track down the problem on 
that yet.  It was working for me a few revisions ago, but not now.  I 
guess I'll add a ticket.

-JJR
Feb 14 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
John Reimer wrote:

 Bill Baxter wrote:

 Bill Baxter wrote:

 Most of this pain of mine would have been avoided if there were 
 working dsss.conf files included with the dwt-samples project.


 And now I see that there is a dsss.conf at the top-level that covers 
 all the subprojects.  Dangit!

 --bb


 
 
 I was confused as to why you were using your own dsss.conf... But, 
 anyway, glad you figured it out.


I didn't expect a top-level dsss.conf.  Maybe I would have expected one 
inside the dwtexamples folder, but the top level of dwt-samples looks so 
disorganized that I totally didn't expect there to be a 
"one-dsss.conf-to-rule-them-all" setup.  That only makes sense to me if 
the expected way to use the samples is to compile them all at once.  But 
I don't think that's generally how people use samples.  They find one 
that's relevant or which they're curious about and compile it.  Having 
the dsss at the top level makes that more complicated because have to cd 
back and forth or specify longer path names a lot.


 Now I recall I had the same problem with dsss and forward slashes.  The 
 strange thing is that dsss reads forward slashes in the dsss.conf file 
 but not on the command line :P.  This is an example of why 
 troubleshooting gets confusing with the problems layered from several 
 technologies. I wish it were easier.


I wish Gregor used Windows.  :-)  Then it would be easier, no doubt.


 About the images in the buttons... Are they missing on yours too?  Are 
 you using Windows XP?  I haven't been able to track down the problem on 
 that yet.  It was working for me a few revisions ago, but not now.  I 
 guess I'll add a ticket.


Yep.  WinXP.  Images missing on the buttons, and toolbars.

--bb
Feb 14 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Bill Baxter wrote:

 John Reimer wrote:

 Bill Baxter wrote:

 Bill Baxter wrote:

 Most of this pain of mine would have been avoided if there were 
 working dsss.conf files included with the dwt-samples project.


 And now I see that there is a dsss.conf at the top-level that covers 
 all the subprojects.  Dangit!

 --bb



 I was confused as to why you were using your own dsss.conf... But, 
 anyway, glad you figured it out.


 
 I didn't expect a top-level dsss.conf.  Maybe I would have expected one 
 inside the dwtexamples folder, but the top level of dwt-samples looks so 
 disorganized that I totally didn't expect there to be a 
 "one-dsss.conf-to-rule-them-all" setup.  That only makes sense to me if 
 the expected way to use the samples is to compile them all at once.  But 
 I don't think that's generally how people use samples.  They find one 
 that's relevant or which they're curious about and compile it.  Having 
 the dsss at the top level makes that more complicated because have to cd 
 back and forth or specify longer path names a lot.
 



Hmm... I got so tired of switching back and forth in these directories 
that I fixed the problem another way: I went the lazy route and 
downloaded Console for Windows (multitabbed CLI from here 
http://sourceforge.net/projects/console).  :)  Yes, I agree it isn't 
necessarily easy the way it works now.

The problem is that the examples will grow to a large number per 
directory and having one dsss.conf per example would not make sense 
either.  I suppose a compromise would be to add a dsss.conf file per 
sample directory instead?  This would certainly make things easier for 
building the larger examples like controlexample.



 Now I recall I had the same problem with dsss and forward slashes.  
 The strange thing is that dsss reads forward slashes in the dsss.conf 
 file but not on the command line :P.  This is an example of why 
 troubleshooting gets confusing with the problems layered from several 
 technologies. I wish it were easier.


 
 I wish Gregor used Windows.  :-)  Then it would be easier, no doubt.
 



Mentioning the two in the same breath is apparently a great evil. :-D



 About the images in the buttons... Are they missing on yours too?  Are 
 you using Windows XP?  I haven't been able to track down the problem 
 on that yet.  It was working for me a few revisions ago, but not now.  
 I guess I'll add a ticket.


 
 Yep.  WinXP.  Images missing on the buttons, and toolbars.
 



Right, I'll continue to look into this.

-JJR
Feb 14 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
John Reimer wrote:

 Bill Baxter wrote:

 John Reimer wrote:

 Bill Baxter wrote:

 Bill Baxter wrote:

 Most of this pain of mine would have been avoided if there were 
 working dsss.conf files included with the dwt-samples project.


 And now I see that there is a dsss.conf at the top-level that covers 
 all the subprojects.  Dangit!

 --bb



 I was confused as to why you were using your own dsss.conf... But, 
 anyway, glad you figured it out.


 I didn't expect a top-level dsss.conf.  Maybe I would have expected 
 one inside the dwtexamples folder, but the top level of dwt-samples 
 looks so disorganized that I totally didn't expect there to be a 
 "one-dsss.conf-to-rule-them-all" setup.  That only makes sense to me 
 if the expected way to use the samples is to compile them all at 
 once.  But I don't think that's generally how people use samples.  
 They find one that's relevant or which they're curious about and 
 compile it.  Having the dsss at the top level makes that more 
 complicated because have to cd back and forth or specify longer path 
 names a lot.


 
 
 Hmm... I got so tired of switching back and forth in these directories 
 that I fixed the problem another way: I went the lazy route and 
 downloaded Console for Windows (multitabbed CLI from here 
 http://sourceforge.net/projects/console).  :)  Yes, I agree it isn't 
 necessarily easy the way it works now.
 
 The problem is that the examples will grow to a large number per 
 directory and having one dsss.conf per example would not make sense 
 either.  I suppose a compromise would be to add a dsss.conf file per 
 sample directory instead?  This would certainly make things easier for 
 building the larger examples like controlexample.


Yes that makes sense.  Actually having multiple dsss.conf's in the same 
directory is only barely, begrudgingly supported by dsss.


 Now I recall I had the same problem with dsss and forward slashes.  
 The strange thing is that dsss reads forward slashes in the dsss.conf 
 file but not on the command line :P.  This is an example of why 
 troubleshooting gets confusing with the problems layered from several 
 technologies. I wish it were easier.


 I wish Gregor used Windows.  :-)  Then it would be easier, no doubt.


 
 
 Mentioning the two in the same breath is apparently a great evil. :-D


I guess that's why my bug reports continue to be ignored.

--bb
Feb 14 2008
prev sibling parent John Reimer <terminal.node gmail.com> writes:
Bill Baxter wrote:


 About the images in the buttons... Are they missing on yours too?  Are 
 you using Windows XP?  I haven't been able to track down the problem 
 on that yet.  It was working for me a few revisions ago, but not now.  
 I guess I'll add a ticket.


 
 Yep.  WinXP.  Images missing on the buttons, and toolbars.
 


I found the problem, but not the solution... yet.

The Activation Context API was used to add XP theme support to dwt 
recently. This fix however appears to be incomplete.  It activates the 
XP theme but apparently the images are still deactivated.

For now, the images will only appear if you have a manifest file like 
controlexample.exe.manifest in the same directory as the executable. 
The Activation Context fix was supposed to fix this too, but apparently 
it is inadequate at the moment.  We will have to look into why this is so.

So, as a temporary solution, here is the controlexample.exe.manifest 
(attached) file from the old dwt project.  Put this is the same 
directory as your controlexample.exe, and the images should show up.

-JJR
Feb 16 2008
prev sibling parent reply Bjoern <nanali nospam-wanadoo.fr> writes:
John Reimer schrieb:

 Bill Baxter wrote:

 Bill Baxter wrote:

 Most of this pain of mine would have been avoided if there were 
 working dsss.conf files included with the dwt-samples project.


 And now I see that there is a dsss.conf at the top-level that covers 
 all the subprojects.  Dangit!

 --bb


 
 
 I was confused as to why you were using your own dsss.conf... But, 
 anyway, glad you figured it out.
 
 Now I recall I had the same problem with dsss and forward slashes.  The 
 strange thing is that dsss reads forward slashes in the dsss.conf file 
 but not on the command line :P.  This is an example of why 
 troubleshooting gets confusing with the problems layered from several 
 technologies. I wish it were easier.
 
 About the images in the buttons... Are they missing on yours too?  Are 
 you using Windows XP?  I haven't been able to track down the problem on 
 that yet.  It was working for me a few revisions ago, but not now.  I 
 guess I'll add a ticket.
 
 -JJR


Pretty confusing

I don't know why but modifying  sc.ini  does the job for me:

DFLAGS="-I% P%\..\import;% P%\..\import\dwt-win" -version=Tango 
-defaultlib=tango-base-dmd.lib -debuglib=tango-base-dmd.lib 
-L+tango-user-dmd.lib

my win xp directory structure :
dmd/import/tango
dmd/import/dwt-win

I use hg within these (adequate) directories.

I can also imagine that Bill is using Tango + Tangobos. Means probabely 
this causes the problem.

However, I am not a dsss fan and I am actually in contact with some 
OCaml folks in order to teach OMake D imports. Not a solution for 
everyone, of course.
Bjoern
Feb 14 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bjoern wrote:

 John Reimer schrieb:

 Bill Baxter wrote:

 Bill Baxter wrote:

 Most of this pain of mine would have been avoided if there were 
 working dsss.conf files included with the dwt-samples project.


 And now I see that there is a dsss.conf at the top-level that covers 
 all the subprojects.  Dangit!

 --bb



 I was confused as to why you were using your own dsss.conf... But, 
 anyway, glad you figured it out.

 Now I recall I had the same problem with dsss and forward slashes.  
 The strange thing is that dsss reads forward slashes in the dsss.conf 
 file but not on the command line :P.  This is an example of why 
 troubleshooting gets confusing with the problems layered from several 
 technologies. I wish it were easier.

 About the images in the buttons... Are they missing on yours too?  Are 
 you using Windows XP?  I haven't been able to track down the problem 
 on that yet.  It was working for me a few revisions ago, but not now.  
 I guess I'll add a ticket.

 -JJR


 
 Pretty confusing
 
 I don't know why but modifying  sc.ini  does the job for me:
 
 DFLAGS="-I% P%\..\import;% P%\..\import\dwt-win" -version=Tango 
 -defaultlib=tango-base-dmd.lib -debuglib=tango-base-dmd.lib 
 -L+tango-user-dmd.lib
 
 my win xp directory structure :
 dmd/import/tango
 dmd/import/dwt-win
 
 I use hg within these (adequate) directories.
 
 I can also imagine that Bill is using Tango + Tangobos. Means probabely 
 this causes the problem.


Yup I am.  I'm not sure what you are saying you modified your sc.ini 
from though.  Are you refering to the -L+tango-user-dmd.lib part?

This seems like an issue that needs attention to me.

I'm using dsss mostly so I can't put that -L+tango-user-dmd part in my 
sc.ini.  That's because dsss puts those functions in libraries called 
something else and links with them automatically.  So adding the -L 
would create lots of multiply defined stuff when I build with dsss.

But I don't always use dsss.  Especially not for small things.  But that 
means when I compile small things I have to add tango-user-dmd.lib to 
the compile line explicitly, which is annoying.  It's part of the 
(alternative) standard library, I shouldn't have to specify it explicitly.

I'm not sure what needs to change to make this annoying dilemma go away. 
  Seems like it would have to be something in DMD itself, unfortunately.


 However, I am not a dsss fan and I am actually in contact with some 
 OCaml folks in order to teach OMake D imports. Not a solution for 
 everyone, of course.


I agree that DSSS is far from perfect.  I think Gregor's biggest mistake 
was to assume that handling D dependencies perfectly would solve all 
build problems (or at least he seems to have made that assumption).  But 
it's just not the case.  In real software there are all kinds of 
dependencies that come from all kinds of places.  A build tool that does 
not have a general dependency engine is a cripple from the outset.

Too bad Gregor has mostly disappeared these days, or maybe DSSS would 
already have such a dependency engine.

--bb
Feb 14 2008
parent reply Bjoern <nanali nospam-wanadoo.fr> writes:
Bill Baxter schrieb:

 Bjoern wrote:

 John Reimer schrieb:

 Bill Baxter wrote:

 Bill Baxter wrote:

 Most of this pain of mine would have been avoided if there were 
 working dsss.conf files included with the dwt-samples project.


 And now I see that there is a dsss.conf at the top-level that covers 
 all the subprojects.  Dangit!

 --bb



 I was confused as to why you were using your own dsss.conf... But, 
 anyway, glad you figured it out.

 Now I recall I had the same problem with dsss and forward slashes.  
 The strange thing is that dsss reads forward slashes in the dsss.conf 
 file but not on the command line :P.  This is an example of why 
 troubleshooting gets confusing with the problems layered from several 
 technologies. I wish it were easier.

 About the images in the buttons... Are they missing on yours too?  
 Are you using Windows XP?  I haven't been able to track down the 
 problem on that yet.  It was working for me a few revisions ago, but 
 not now.  I guess I'll add a ticket.

 -JJR


 Pretty confusing

 I don't know why but modifying  sc.ini  does the job for me:

 DFLAGS="-I% P%\..\import;% P%\..\import\dwt-win" -version=Tango 
 -defaultlib=tango-base-dmd.lib -debuglib=tango-base-dmd.lib 
 -L+tango-user-dmd.lib

 my win xp directory structure :
 dmd/import/tango
 dmd/import/dwt-win

 I use hg within these (adequate) directories.

 I can also imagine that Bill is using Tango + Tangobos. Means 
 probabely this causes the problem.


 
 Yup I am.  I'm not sure what you are saying you modified your sc.ini 
 from though.  Are you refering to the -L+tango-user-dmd.lib part?
 
 This seems like an issue that needs attention to me.
 


Well in case that you install a naked Tango + dmd 1.025
your sc.ini DFALGS stuff is a s follows :

DFLAGS="-I% P%\..\import" -version=Tango
-defaultlib=tango-base-dmd.lib -debuglib=tango-base-dmd.lib
-L+tango-user-dmd.lib

As you can see, I just added :
;% P%\..\import\dwt-win"

the -L flag seems to be not nessesary in case that you use Tango + 
Tangobos. (I mean the optional ready-to-use installation, you can 
download from Tango)
just compare it.

Beside I use Tango rev 3172


 I agree that DSSS is far from perfect.  I think Gregor's biggest mistake 
 was to assume that handling D dependencies perfectly would solve all 
 build problems (or at least he seems to have made that assumption).  But 
 it's just not the case.  In real software there are all kinds of 
 dependencies that come from all kinds of places.  A build tool that does 
 not have a general dependency engine is a cripple from the outset.
 


OT/
Do not want to say too much because not much is done at the moment but I 
choose Omake :

Quote : http://omake.metaprl.org/index.html
...
Built-in functions that provide the most common features of programs 
like grep, sed, and awk. These are especially useful on Win32.
Active filesystem monitoring, where the build automatically restarts 
whenever you modify a source file. This can be very useful during the 
edit/compile cycle.  Really ??? :)

and I've just received a mail from a guy who did his ADA build work 
using OMake. Interesting 'cause ADAs import/package handling is at least 
as complicated as Ds. )
Bjoern
Feb 14 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bjoern wrote:

 Bill Baxter schrieb:

 Bjoern wrote:

 John Reimer schrieb:

 Bill Baxter wrote:

 Bill Baxter wrote:

 Most of this pain of mine would have been avoided if there were 
 working dsss.conf files included with the dwt-samples project.


 And now I see that there is a dsss.conf at the top-level that 
 covers all the subprojects.  Dangit!

 --bb



 I was confused as to why you were using your own dsss.conf... But, 
 anyway, glad you figured it out.

 Now I recall I had the same problem with dsss and forward slashes.  
 The strange thing is that dsss reads forward slashes in the 
 dsss.conf file but not on the command line :P.  This is an example 
 of why troubleshooting gets confusing with the problems layered from 
 several technologies. I wish it were easier.

 About the images in the buttons... Are they missing on yours too?  
 Are you using Windows XP?  I haven't been able to track down the 
 problem on that yet.  It was working for me a few revisions ago, but 
 not now.  I guess I'll add a ticket.

 -JJR


 Pretty confusing

 I don't know why but modifying  sc.ini  does the job for me:

 DFLAGS="-I% P%\..\import;% P%\..\import\dwt-win" -version=Tango 
 -defaultlib=tango-base-dmd.lib -debuglib=tango-base-dmd.lib 
 -L+tango-user-dmd.lib

 my win xp directory structure :
 dmd/import/tango
 dmd/import/dwt-win

 I use hg within these (adequate) directories.

 I can also imagine that Bill is using Tango + Tangobos. Means 
 probabely this causes the problem.


 Yup I am.  I'm not sure what you are saying you modified your sc.ini 
 from though.  Are you refering to the -L+tango-user-dmd.lib part?

 This seems like an issue that needs attention to me.


 Well in case that you install a naked Tango + dmd 1.025
 your sc.ini DFALGS stuff is a s follows :
 
 DFLAGS="-I% P%\..\import" -version=Tango
 -defaultlib=tango-base-dmd.lib -debuglib=tango-base-dmd.lib
 -L+tango-user-dmd.lib
 
 As you can see, I just added :
 ;% P%\..\import\dwt-win"


Ok.  Well that makes sense you'd need that if you've got libs that need 
to be linked with in your import\dwt-win directory.  There should be 
some flag to add that during compilation too.  With dsss you can add 
extra lib dirs using "-S..\import\dwt-win".


 the -L flag seems to be not nessesary in case that you use Tango + 
 Tangobos. (I mean the optional ready-to-use installation, you can 
 download from Tango)
 just compare it.
 
 Beside I use Tango rev 3172.


Hmm.  I'm confused then because the Windows install instructions on the 
Tango page make it sound like the -L is an optional thing not included 
by default, but you can add it if you feel like it.  But you're saying 
it is the default in the pre-made Tango packages?


 I agree that DSSS is far from perfect.  I think Gregor's biggest 
 mistake was to assume that handling D dependencies perfectly would 
 solve all build problems (or at least he seems to have made that 
 assumption).  But it's just not the case.  In real software there are 
 all kinds of dependencies that come from all kinds of places.  A build 
 tool that does not have a general dependency engine is a cripple from 
 the outset.


 OT/
 Do not want to say too much because not much is done at the moment but I 
 choose Omake :
 
 Quote : http://omake.metaprl.org/index.html
 ...
 Built-in functions that provide the most common features of programs 
 like grep, sed, and awk. These are especially useful on Win32.
 Active filesystem monitoring, where the build automatically restarts 
 whenever you modify a source file. This can be very useful during the 
 edit/compile cycle.  Really ??? :)
 
 and I've just received a mail from a guy who did his ADA build work 
 using OMake. Interesting 'cause ADAs import/package handling is at least 
 as complicated as Ds. )
 Bjoern


Hmm haven't heard much about OMake.  I think SCons is probably more 
widely used and actively developed, though, if you're going to go the 
route of adding D support to an existing build tool.  And someone has 
already done some work getting D support into SCons.

--bb
Feb 14 2008
parent reply Bjoern <nanali nospam-wanadoo.fr> writes:
Bill Baxter schrieb:

 Bjoern wrote:

 Bill Baxter schrieb:

 Bjoern wrote:

 John Reimer schrieb:

 Bill Baxter wrote:

 Bill Baxter wrote:

 Most of this pain of mine would have been avoided if there were 
 working dsss.conf files included with the dwt-samples project.


 And now I see that there is a dsss.conf at the top-level that 
 covers all the subprojects.  Dangit!

 --bb



 I was confused as to why you were using your own dsss.conf... But, 
 anyway, glad you figured it out.

 Now I recall I had the same problem with dsss and forward slashes.  
 The strange thing is that dsss reads forward slashes in the 
 dsss.conf file but not on the command line :P.  This is an example 
 of why troubleshooting gets confusing with the problems layered 
 from several technologies. I wish it were easier.

 About the images in the buttons... Are they missing on yours too?  
 Are you using Windows XP?  I haven't been able to track down the 
 problem on that yet.  It was working for me a few revisions ago, 
 but not now.  I guess I'll add a ticket.

 -JJR


 Pretty confusing

 I don't know why but modifying  sc.ini  does the job for me:

 DFLAGS="-I% P%\..\import;% P%\..\import\dwt-win" -version=Tango 
 -defaultlib=tango-base-dmd.lib -debuglib=tango-base-dmd.lib 
 -L+tango-user-dmd.lib

 my win xp directory structure :
 dmd/import/tango
 dmd/import/dwt-win

 I use hg within these (adequate) directories.

 I can also imagine that Bill is using Tango + Tangobos. Means 
 probabely this causes the problem.


 Yup I am.  I'm not sure what you are saying you modified your sc.ini 
 from though.  Are you refering to the -L+tango-user-dmd.lib part?

 This seems like an issue that needs attention to me.


 Well in case that you install a naked Tango + dmd 1.025
 your sc.ini DFALGS stuff is a s follows :

 DFLAGS="-I% P%\..\import" -version=Tango
 -defaultlib=tango-base-dmd.lib -debuglib=tango-base-dmd.lib
 -L+tango-user-dmd.lib

 As you can see, I just added :
 ;% P%\..\import\dwt-win"


 
 Ok.  Well that makes sense you'd need that if you've got libs that need 
 to be linked with in your import\dwt-win directory.  There should be 
 some flag to add that during compilation too.  With dsss you can add 
 extra lib dirs using "-S..\import\dwt-win".
 

 the -L flag seems to be not nessesary in case that you use Tango + 
 Tangobos. (I mean the optional ready-to-use installation, you can 
 download from Tango)
 just compare it.

 Beside I use Tango rev 3172.


 
 Hmm.  I'm confused then because the Windows install instructions on the 
 Tango page make it sound like the -L is an optional thing not included 
 by default, but you can add it if you feel like it.  But you're saying 
 it is the default in the pre-made Tango packages?
 


Yes, at least for Tango Frank + dmd as well as Tango snapshot plus dmd 1.025

The -L flag seems to have some side effects. For example creating pure 
Tango based DLLs is not possible. First you've to remove this flag.
According to Sean K :
I don't know what we need the L flag for, but I am sure it had a 
reason.......


 Hmm haven't heard much about OMake.  I think SCons is probably more 
 widely used and actively developed, though, if you're going to go the 
 route of adding D support to an existing build tool.  And someone has 
 already done some work getting D support into SCons.


In France OCaml is in industry use, Airbus/ESA. France Telecom. Means 
OMake is still alive. Hope I got the chance to introduce D in 
Toulouse/Airbus this summer.


 
 --bb
Feb 14 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bjoern wrote:

 Bill Baxter schrieb:

 Bjoern wrote:

 Bill Baxter schrieb:

 Bjoern wrote:

 John Reimer schrieb:

 Bill Baxter wrote:

 Bill Baxter wrote:

 Most of this pain of mine would have been avoided if there were 
 working dsss.conf files included with the dwt-samples project.


 And now I see that there is a dsss.conf at the top-level that 
 covers all the subprojects.  Dangit!

 --bb



 I was confused as to why you were using your own dsss.conf... But, 
 anyway, glad you figured it out.

 Now I recall I had the same problem with dsss and forward 
 slashes.  The strange thing is that dsss reads forward slashes in 
 the dsss.conf file but not on the command line :P.  This is an 
 example of why troubleshooting gets confusing with the problems 
 layered from several technologies. I wish it were easier.

 About the images in the buttons... Are they missing on yours too?  
 Are you using Windows XP?  I haven't been able to track down the 
 problem on that yet.  It was working for me a few revisions ago, 
 but not now.  I guess I'll add a ticket.

 -JJR


 Pretty confusing

 I don't know why but modifying  sc.ini  does the job for me:

 DFLAGS="-I% P%\..\import;% P%\..\import\dwt-win" -version=Tango 
 -defaultlib=tango-base-dmd.lib -debuglib=tango-base-dmd.lib 
 -L+tango-user-dmd.lib

 my win xp directory structure :
 dmd/import/tango
 dmd/import/dwt-win

 I use hg within these (adequate) directories.

 I can also imagine that Bill is using Tango + Tangobos. Means 
 probabely this causes the problem.


 Yup I am.  I'm not sure what you are saying you modified your sc.ini 
 from though.  Are you refering to the -L+tango-user-dmd.lib part?

 This seems like an issue that needs attention to me.


 Well in case that you install a naked Tango + dmd 1.025
 your sc.ini DFALGS stuff is a s follows :

 DFLAGS="-I% P%\..\import" -version=Tango
 -defaultlib=tango-base-dmd.lib -debuglib=tango-base-dmd.lib
 -L+tango-user-dmd.lib

 As you can see, I just added :
 ;% P%\..\import\dwt-win"


 Ok.  Well that makes sense you'd need that if you've got libs that 
 need to be linked with in your import\dwt-win directory.  There should 
 be some flag to add that during compilation too.  With dsss you can 
 add extra lib dirs using "-S..\import\dwt-win".


 the -L flag seems to be not nessesary in case that you use Tango + 
 Tangobos. (I mean the optional ready-to-use installation, you can 
 download from Tango)
 just compare it.

 Beside I use Tango rev 3172.


 Hmm.  I'm confused then because the Windows install instructions on 
 the Tango page make it sound like the -L is an optional thing not 
 included by default, but you can add it if you feel like it.  But 
 you're saying it is the default in the pre-made Tango packages?


 
 Yes, at least for Tango Frank + dmd as well as Tango snapshot plus dmd 
 1.025
 
 The -L flag seems to have some side effects. For example creating pure 
 Tango based DLLs is not possible. First you've to remove this flag.
 According to Sean K :
 I don't know what we need the L flag for, but I am sure it had a 
 reason.......
 

 Hmm haven't heard much about OMake.  I think SCons is probably more 
 widely used and actively developed, though, if you're going to go the 
 route of adding D support to an existing build tool.  And someone has 
 already done some work getting D support into SCons.


 
 In France OCaml is in industry use, Airbus/ESA. France Telecom. Means 
 OMake is still alive. Hope I got the chance to introduce D in 
 Toulouse/Airbus this summer.


I'm not saying OMake is dead, just talking various magnitudes of 
alive-ness.  The idea of SCons makes sense.  Rather than create a 
half-baked mini-language to describe build tasks use a real full-fledged 
language.  Python is meant to be an easy language that anyone can pick 
up, so it's a good candidate.

I guess my real gut feeling though is that the best solution would be a 
half-baked declarative mini-language with the ability to include 
arbitrary code from a "real" language at any point.  For describing 
basic dependencies and actions to perform based on them you really can't 
get much simpler than Make's syntax.

--bb
Feb 14 2008
prev sibling parent reply DBloke <DBloke nowhere.org> writes:
 In France OCaml is in industry use, Airbus/ESA. France Telecom. Means 
 OMake is still alive. Hope I got the chance to introduce D in 
 Toulouse/Airbus this summer.
 

 --bb





used by companies like Microsoft to build compilers :) Functional 
languages are not new Lisp has been around for years, but they are just 
starting to find their way into OO languages now, even D borrows from 
the functional paradigm with lazy evaluation, lazy I call it common 
sense ;) OMake is useful and could easily be utilised for D!

I am trying to educate the engineering bods in our work place about 
alternatives to Java and C++ mainly D and OCaml, sadly the arguments I 
get are related to lack of a decent IDE and Thin client support.

I will continue to chip away and you never know :)
Feb 14 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
DBloke wrote:

 

 In France OCaml is in industry use, Airbus/ESA. France Telecom. Means 
 OMake is still alive. Hope I got the chance to introduce D in 
 Toulouse/Airbus this summer.


 --bb




 

 used by companies like Microsoft to build compilers :) Functional 
 languages are not new Lisp has been around for years, but they are just 
 starting to find their way into OO languages now, even D borrows from 
 the functional paradigm with lazy evaluation, lazy I call it common 
 sense ;) OMake is useful and could easily be utilised for D!
 
 I am trying to educate the engineering bods in our work place about 
 alternatives to Java and C++ mainly D and OCaml, sadly the arguments I 
 get are related to lack of a decent IDE and Thin client support.
 
 I will continue to chip away and you never know :)


OCaml is certainly not bad.  I actually had decided to make it my 
primary compiled language about a year or so ago after getting fed up 
with C++.  But the switch was just too difficult for an old time C++ 
user.  It wasn't obvious how I should do anything.  And I think the 
places where functional code shines are pretty much exactly the places 
where I don't go very often.  OCaml's support for fast numerics was what 
attracted me initially, plus I knew some ML from school, but in the end 
I just found it too painful to switch.  For instance it's not so easy to 
translate C/C++ code I have written or which I find on the web to OCaml.

D on the other hand makes for a very smooth transition.   And in a 
pretty short time I was able to use it, know exactly what was going on, 

exists in D etc.  (Or call directly into C libs if they're too big to port).

I think the main problem with functional languages is that they're just 
so darned functional, and procedural additions like monads seem 
heavy-handed and cumbersome.  Adding a dose of functional features to a 
procedural language, however, works pretty well and lets you only use 
the functional stuff where you really need it.

Anyway, I wish OCaml luck, but it really is fighting an uphill battle.

--bb
Feb 14 2008