View mode: basic / threaded / horizontal-split · Log in · Help
August 28, 2007
Re: DSSS and multiple intermingled environments
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?
August 28, 2007
Re: DSSS and multiple intermingled environments
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
August 29, 2007
Re: DSSS and multiple intermingled environments
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.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home