Fix dependency chains in posix.mak

[wilzbach]

1. The idea of a build system is that only the files that need to be updated, should be. This PR is an attempt to fix this as since the move to generated this isn't the case anymore (at the moment every build is a full rebuild
2. The generated dmd.conf needs to be put into the generated folder as well
3. There was an issue with the dependency chain of the C files. An update to the source files didn't trigger the dependency chain. The reason for this problem was that the generated dependency files need to be included before their rule)
4. The optagen output target was completely broken

• the targets didn't exist
• if run in parallel, it would run the tool was well in parallel

For more infos on (4) see this guide or this SO question.

CC @RazvanN7

[wilzbach]

@andralex while I really appreciate the fast review and intend to merge I think we shouldn't overrun the usual one-day "cry loud if you can" waiting period, especially as this is non-trivial and there were some issues with CircleCi.
(though they are caused by CircleCi expecting dmd.conf to be in src ...)

[wilzbach]

This might be the biggest proposed change but I couldn't see any reason why we shouldn't auto-generate the dmd.conf into generated during a normal build.

[MartinNowak]

Yes it should, but it also needs to be copied to src/dmd.conf while we're still using that.
Also the target for make -C src -f posix.mak dmd.conf (src/posix.mak) is used in many places.

[wilzbach]

Yes it should, but it also needs to be copied to src/dmd.conf while we're still using that.

Well, we can't copy it because the relative paths are different, but I put the "old" dmd.conf target back in.
Once @RazvanN7 does the ddmd -> dmd transition, he should be able to remove this legacy target :)

Also the target for make -C src -f posix.mak dmd.conf (src/posix.mak) is used in many places.

Yup I noticed - the Travis and CircleCi scripts have this behavior.

[MartinNowak]

One reason this wasn't done previously is that a dmd.conf in the current working dir applies to any dmd being run, it has the highest precedence in the config search order. Super-annoying IMO, but I won't argue any more.
Since we've switched to explicit -conf= it shouldn't cause much troubles.

[wilzbach]

See also: https://github.com/dlang/druntime/pull/1786/files

[wilzbach]

there were some issues with CircleCi.

I think I have won the fight against CircleCi & Travis :)

[MartinNowak]

How do you generate the [SQUASH] commit messages? Tried git-rebase with --autosquash but it doesn't understand those, nor the squash! [SQUASH] message ones create with git commit --squash HEAD~1.

[MartinNowak]

Except for complex PR reviews the value of adding new changes as tiny commits and later squashing seems very small compare to all the extra decisions/complications it adds.

[wilzbach]

How do you generate the [SQUASH] commit messages?

Manually. I though it doesn't matter, because with auto-merge-squash all commits will be squashed into one anyways.
I will use --fixup in the future then.

the value of adding new changes as tiny commits and later squashing seems very small compare to all the extra decisions/complications it adds.

Well again, the idea is that one doesn't have to look at the entire diff if only one line changed and again with auto-merge-squash there wouldn't be extra costs involved.