Why isn't DSSS ('s net portion) more widely used?

[Pragma]

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