DSSS and multiple intermingled environments

[Bill Baxter]

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.