DSSS and multiple intermingled environments

[Gregor Richards]

Johan Granberg wrote:
> 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 think distclean should [n]ever be a solution.

Neither do I. But detecting environment changes is not always possible. 
It would be easy enough to detect changed flags at build time and then 
clean up old things before building, but that's a nonsolution after 
installing it. DSSS was not designed to rectify all the problems with 
combining DMD and GDC, Phobos and Tango.

> Wouldn't it be better if
> there was a way to specify separate locations for binaries for the
> different compiler/stdlib combinations in the dsss.conf file?
> (gdc-phobos-bin,dmd-tango-bin,etc...)

No, that would not be better. That would mean that one person could 
write a dsss.conf file for their library that would work with building 
on multiple compilers, and the next person would write one that didn't. 
Builds should not be this inconsistent. Besides that, it would make 
dsss.conf files unduly complex. Besides that, it builds flexibility 
limits into DSSS, making it assume that there will only ever be two 
compilers.

> 
> Personally i consider the need to remove object files before a build a bug
> in the build system  and try to write makefiles (or other commandfiles) to
> not require any make clean or similar.

Unless your makefiles also solve the halting problem, they cannot detect 
all such scenarios. Try making, then doing `make 
CC=incompatible_c_compiler`. The autotools "solve" this very much like 
DSSS does - if you want to suddenly use a different compiler, you have 
to clean up and start again. Try reconfiguring with a different compiler 
and then just typing `make` - if you're really lucky, it'll clean up for 
you. If you're not, it'll fail miserably. This only works for autotools 
because it has a configure "lock-in" phase that DSSS does not have - it 
can detect most environmental changes because it locks you into an 
environment.

As I've said over and over again: Detecting when the environment has 
changed in an incompatible way is an arbitrary-complexity problem.

> 
>> 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.
>>
>>   - Gregor Richards
> 
> ps. while we already are talking dsss deficiencies will it be possible to
> run your own repositories (think of how git works) and specify in the
> dsss.conf that this lib is from here and that lib from there etc ... ?

The dsss.conf would be a wholly-inappropriate place to specify this. As 
per having multiple upstream sources, that's a possibility that will 
enter into it as I add the variety of changes to the source system that 
are coming in with DSource integration.

  - Gregor Richards