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:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

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.
 

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.

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.

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.

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.

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


OCaml is an excellent language as is F# and Haskell These languages are 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


OCaml is an excellent language as is F# and Haskell These languages are 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, and was able to easily to port C/C++/Java/C# code where nothing native 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