documentation: buildflags in [*] don't combine with those in [named] section

Ack, should have used wiki formatting:

[myprog.d]
buildflags += -Isomething

[*] 
buildflags += -Isomething_else

This is a problem I've run into before, but the fix ended up causing more problems than the problem. Basically, if I make this:

[*]
buildflags = whatever

[somelib]
version (Windows) {
    buildflags = -Iblah
}
buildflags += -Sfoo

It is now ambiguous what I want to be done, and would work differently on different platforms. Whoops 8-X

Anyway, last time this came up is when I added the 'set' and 'add' hook commands. If you absolutely need some certain build flags to be combined into all the other sections, you can use:

[+buildflags]
prebuild=add *:buildflags -forced-buildflags

[somelib]
buildflags = -Sfoobork

Because 'add' runs after parsing everything else, it will be added to everything.

I'll keep this open as a documentation ticket, but making them actually combine isn't going to happen. (Well, unless you can suggest a way that would be totally unambiguous)

What I would expect to happen would be that it would work in lexical order. So if [*] comes first then it acts as if stuff in [*] gets executed first. Of course then you might want to allow multiple [*] sections so that stuff can get added in multiple places...

Another thing that would help reduce the redundancy when you have many common settings between projects would be a generic way to set user variables. Then I could do

MYFLAGS=-Igeneric/includes -Iglobal/includes

[project]
buildflags+=$MYFLAGS -Ifunktastic

[example]
buildflags+=$MYFLAGS -version=Example

This is now documented properly. As per actual changes, I'm going to keep this ticket open for reference in a later release.

And yeah, why doesn't DSSS let you set environment variables? X_X

I didn't mean it should set environment variables. I meant that it should let you set variables. Setting a variable would do nothing to the external environment.