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

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

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

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

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

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

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

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

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

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