Reply to Gregor,

> BCS wrote:
> 
>> Reply to Gregor,
>> 
>>> I'm not sure which of two questions you're asking here (which isn't
>>> surprising since the net architecture is a bit complicated), so I'll
>>> just answer both:
>>> 
>> this question
>> 
>>> So what would it take to let the user use a different list of
>>> sources from which `dsss net` will download libraries?
>>> 
>>> Currently you can only specify one at a time, but the --source
>>> option exists for this purpose.
>>> 
>> Cool, what would it take to set up my own list server? If it is easy,
>> It would let me play with DSSS locally. (My main dev system has, by
>> design, no net access)
>> 
>>> - Gregor Richards
>>> 
> In docs/README.technical, read the section on 'net installation'. It
> may or may not be sufficient (nobody has ever really used it as a
> reference :) ), so suggestions for improvements would be appreciated.
> 
> - Gregor Richards
> 

So If I generate the listed files and stuff them on an HTTP server, I can get dsss to play with it?
How is the pkgs.list file generated? Do you have any tools for making life easy for someone trying to set up a system?

BCS wrote:
> Reply to Gregor,
> 
>> BCS wrote:
>>
>>> Reply to Gregor,
>>>
>>>> I'm not sure which of two questions you're asking here (which isn't
>>>> surprising since the net architecture is a bit complicated), so I'll
>>>> just answer both:
>>>>
>>> this question
>>>
>>>> So what would it take to let the user use a different list of
>>>> sources from which `dsss net` will download libraries?
>>>>
>>>> Currently you can only specify one at a time, but the --source
>>>> option exists for this purpose.
>>>>
>>> Cool, what would it take to set up my own list server? If it is easy,
>>> It would let me play with DSSS locally. (My main dev system has, by
>>> design, no net access)
>>>
>>>> - Gregor Richards
>>>>
>> In docs/README.technical, read the section on 'net installation'. It
>> may or may not be sufficient (nobody has ever really used it as a
>> reference :) ), so suggestions for improvements would be appreciated.
>>
>> - Gregor Richards
>>
> 
> So If I generate the listed files and stuff them on an HTTP server, I can get dsss to play with it?
> How is the pkgs.list file generated? Do you have any tools for making life easy for someone trying to set up a system?
> 
> 

As mentioned in the last section of that file, pkgs.list is generated by pkgslist.d. I suppose I should mention in there that the file pkgslist.d is at
http://svn.dsource.org/projects/dsss/sources/pkgslist.d (which is in the default sources archive). Mayhaps that should move somewhere a bit more accessible too ...

Oh, right, answering the question (will get step documented better later). Within the directory with your sources.list, run pkgslist. It will download all the sources, trace imports, and create pkgs.list.

 - Gregor Richards

Gregor Richards wrote:
> DSSS seems to be getting a lot of flak recently because it's not particularly happy being used with multiple versions of DMD, GDC, etc all layered together.
> 
> This is hardly fair to DSSS. Detecting such situations is an arbitrary-complexity problem, and DSSS can never really know what has been changed under it. It can make some reasonable guesses, but since IMHO those would usually been wrong, I've erred on the side of ignorance. That is, if you're going to change DSSS' underlying compilation environment, it anticipates that you will consider the consequences and `dsss distclean` first.

I don't expect DSSS to detect all situations.  But I think it would make sense to store build products created using 'some-profile' under directories specific to 'some-profile' or filenames specific to 'some-profile'.  That's pretty much the approach boostjam takes.  It creates lots of very hugely nested directory trees and libraries with very long names, but it seems to work well.

As for the di files, I think you can make it work better with multi-flavor builds by importing the pragma link bit rather than embedding it directly in the di.

So you replace this bit at the end of each installed .di:

version (build) {
    pragma(link, "SDD-somelib");
}

with something like

import current.package.name.somelib-linkstub;

And put somelib-linkstub.d in a build-specific include directory, containing the build-specific pragma above.

Or maybe easier would be to just make pragma link smart enough to infer the prefix (that's a rebuild feature, right? I guess then the problem is that rebuild doesn't know about DSSS's conventions.)

> I don't know whether this situation will improve. To be honest, I hardly consider the fact that DSSS is not psychic a bug. As I already said, it's not something that can be fixed magically, it's actually quite complex. If you're going to be forcing DSSS to jump through multiple environments, just clean up after yourself.
> 
> Do a `dsss distclean` before building with a different compiler.

That's not a very good solution to the problem of maintaining multi-flavored builds.  Currently if someone wants to make a library available to people in more than one config, testing the different configs means they have to basically re-install from scratch every library that their library depends on before rebuilding their own library and test apps [1].  DSSS is set up to handle a DMD/GDC distinction in the libraries with that type code in the names.  That's good. But the version-specific pragma(link,...) in the di files prevents that from being very helpful.  And DSSS net's penchant for destroying builds of a different flavor than the current one is also a problem.

Ok, so there are really two issues here - one is how dsss installs stuff (the pragmas added to .di's and blowing away different lib versions). And the other is how it builds stuff locally.  The install problem I would call major.  The fact that local build products all go in the same dsss_imports and dsss_objs directories is a less serious issue, but it's still an issue when it comes to scalability.  If I need to go between dmd and gdc builds -- or even release and debug builds -- of some-huge-project, it could take a lot of time to switch if I'm required to distclean every time.  Perhaps for the local build products there could be a way for the user to specify project 'configs' that would control the subdirectory into which build products are placed.

--bb

[1] I guess an alternative would be to maintain 2 (or more) completely separate dsss installs that you switch between by manipulating your PATH variable.