Pragma wrote:
> Lars Ivar Igesund wrote:
>> Pragma wrote:
>>
>>> I'm still finding it hard to develop reasonably complex DSSS scripts only
>>> because there's only one possible mode of
>>> testing them: net install.  There's no option to execute dsss.conf from
>>> the filesystem (via "-file <filename>" or
>>> somesuch), so I can't test my dsss.conf file out locally before exposing
>>> it to the world (unless I'm mistaken).  IMO, that's a big problem.
>>
>> Why can't you use "dsss build" and "dsss install" ?
>>
> 
> Hrm... maybe I missed an update somewhere along the way.  Does it still look only in the current path, or can you specify a path for the dsss.conf file via those two methods?
> 

Yes, it still only looks in the current path. I haven't added your -file option for two reasons:
    1) I have no idea why it's supposed to be useful.
    2) Nobody else has asked for it.

No wait, three reasons:
    3) It becomes very ambiguous if you have a subdirectory with its own dsss.conf file: Then you have to answer the question "Should it look at that dsss.conf file, or one relative to the -file provided one?" And whichever way I answer that, 50% of the people who use this feature will think my answer is wrong. Hell, I'll think my own answer is wrong.

No! Four reasons:
    4) Having the dsss.conf file next to the source just makes sense. While /allowing/ it to be elsewhere is hardly /forcing/ it to be elsewhere, it does encourage confusion. I'd hate to see people go "well, I'm not sure how to integrate my Windows-only dsss.conf and my GNU/Linux-only dsss.conf (using version() blocks is soooooooooo confusing), so I'll just require you to run dsss build -file dsssConfDir/windows/dsss.conf"

And, I completely fail to understand how "have to modify the dsss.conf file in place" leads to "can't test it before exposing it to the world."

 - Gregor Richards

Gregor Richards wrote:
> Pragma wrote:
>> Lars Ivar Igesund wrote:
>>> Pragma wrote:
>>>
>>>> I'm still finding it hard to develop reasonably complex DSSS scripts only
>>>> because there's only one possible mode of
>>>> testing them: net install.  There's no option to execute dsss.conf from
>>>> the filesystem (via "-file <filename>" or
>>>> somesuch), so I can't test my dsss.conf file out locally before exposing
>>>> it to the world (unless I'm mistaken).  IMO, that's a big problem.
>>>
>>> Why can't you use "dsss build" and "dsss install" ?
>>>
>>
>> Hrm... maybe I missed an update somewhere along the way.  Does it still look only in the current path, or can you specify a path for the dsss.conf file via those two methods?
>>
> 
> Yes, it still only looks in the current path. I haven't added your -file option for two reasons:
>     1) I have no idea why it's supposed to be useful.
>     2) Nobody else has asked for it.
> 
> No wait, three reasons:
>     3) It becomes very ambiguous if you have a subdirectory with its own dsss.conf file: Then you have to answer the question "Should it look at that dsss.conf file, or one relative to the -file provided one?" And whichever way I answer that, 50% of the people who use this feature will think my answer is wrong. Hell, I'll think my own answer is wrong.
> 
> No! Four reasons:
>     4) Having the dsss.conf file next to the source just makes sense. While /allowing/ it to be elsewhere is hardly /forcing/ it to be elsewhere, it does encourage confusion. I'd hate to see people go "well, I'm not sure how to integrate my Windows-only dsss.conf and my GNU/Linux-only dsss.conf (using version() blocks is soooooooooo confusing), so I'll just require you to run dsss build -file dsssConfDir/windows/dsss.conf"

Good point.  Let me ask you this then: is it possible to pass -version through DSSS to the .conf file?  I'd be more than happy to maintain things from a single root .dsss file if I can provide different install options in some fashion. Barring that, what is the recommended way to set up sub-projects that share the same root; that's really all that I'm after.

Take DDL for instance: there's the SDK (everything), and the pre-built utilities package. The former includes both, where the latter should be stand-alone.  Currently, DSSS will only let me support the "everything" option.

There's also projects like Enki that have a similar split, as it's a binary bundled with a runtime library for use with generated code.  So having the binary's sourcecode *optionally* installed would be a plus, as to reduce confusion. Otherwise, your best option is to install using --prefix, which would dump the runtime library outside the main library location.

> 
> And, I completely fail to understand how "have to modify the dsss.conf file in place" leads to "can't test it before exposing it to the world."
> 
>  - Gregor Richards


No worries Gregor. :)  Obviously, I'm not up to speed with DSSS yet, and have yet to completely grok how things are supposed to work.  Frankly, I'm glad to be mistaken - that means I'm the only one stuck ATM, which is a good thing for DSSS.

-- 
- EricAnderton at yahoo

Robert Fraser wrote:
> DSSS seems like a great tool, but only a very small subset of available D libraries are installable via it. I can see it turning into something like CPAN, where you can easily get a module and its required dependencies, without really having to worry about version compatibility, etc, etc. ANy ideas on why it's not more widely used?

Looking at the docs for 0.65 (README.overview), I see it says that it's based on bud.  Is that correct?  Are bud and rebuild the same thing, or did the project switch over to using bud instead of rebuild?

On Mon, 04 Jun 2007 22:08:49 -0400, Jason House wrote:

> Robert Fraser wrote:
>> DSSS seems like a great tool, but only a very small subset of available D libraries are installable via it. I can see it turning into something like CPAN, where you can easily get a module and its required dependencies, without really having to worry about version compatibility, etc, etc. ANy ideas on why it's not more widely used?
> 
> Looking at the docs for 0.65 (README.overview), I see it says that it's based on bud.  Is that correct?  Are bud and rebuild the same thing, or did the project switch over to using bud instead of rebuild?

As far as I know, Gregor took some of the concepts in Bud and wrote Rebuild from the DigitalMars C++ source code of the D-frontend.

They are not the same product even though they overlap with some of their functionality.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
5/06/2007 1:20:41 PM

Jason House wrote:
> Robert Fraser wrote:
>> DSSS seems like a great tool, but only a very small subset of available D libraries are installable via it. I can see it turning into something like CPAN, where you can easily get a module and its required dependencies, without really having to worry about version compatibility, etc, etc. ANy ideas on why it's not more widely used?
> 
> Looking at the docs for 0.65 (README.overview), I see it says that it's based on bud.  Is that correct?  Are bud and rebuild the same thing, or did the project switch over to using bud instead of rebuild?

Outdated documentation bug. Thanks for pointing that out. It does indeed use rebuild.

 - Gregor Richards