DSSS and multiple intermingled environments

Johan Granberg lijat.meREM at OVEgmail.com
Tue Aug 28 10:00:18 PDT 2007


Gregor Richards wrote:

> 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.

In what way? if the binaries lives in a project subdirectory named after the
compiler and standard library like cc-stdlib-bin and dsss always uses this
to place binaries. That way when the compiler or standard library was
swapped dsss would use a different directory and no conflicts would occur.

It is possible that I missunderstand the issue but in that case whats wrong
with the above system?

>> 
>>> 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

Where else if not dsss.conf? The way I envisioned it was a line per hos used
something like this.
with host1.addres1.com
with host2.addres2.org
possibly with specifiers for which library to get from where.

Personally this is an extremely important feature to have. It would mean
that I don't need to trust some external central point of failure to host
my project.



More information about the Digitalmars-d mailing list