Another dwt-win / dmd / dsss build problem

[Bill Baxter]

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