Explicit Feedback on Layout Change

With [1b94560] push an Advanced Policy comes with a verbose build steps.
Now after modifying a source the build process informs about what has changed in *.ld layout since previous build (this is planned to be changed and compared against previous memory content, not previous build as not every build is programmed into memory).

From there it should be quite easy to provide a more descriptive way of what has been changed and why some modifications cause ROM content change (and impose time-consuming reflashing).

Current implementation informs only about the layout change (informs about change of the location of some resource in memory). However there is no information given about the change of the resource as such so far.

• if we make a resource move from ROM to RAM then that is indicated
• if we change only the size of the resource then that is not indicated

in the build report.

This is on my todo list.

Update 20140503:
The initial aim of SplitCode was to create a basic, bulletproof yet complete solution for those ld-unskilled. Unfortunately because of the above "incompleteness" I am afraid this is not going to happen. Well, SplitCode is going to proceed but the goal would have to be revised.
Previously I was thinking about a version suitable for everyone familiar with a raw build process. One must understand that because SplitCode boosts performance, it must be made at some price. The price is a huge amount of dumb/simple constrains one has to face. All of the constrains are managed by SplitCode policy transparently and it always pushes out "the best" elf it possibly can. The problem is that it is enough to violate single one of the constrains and the whole advantage of SplitCode idea vanishes == produces elf that requires ROM flashing.
So then I thought explicit hints about violations are what I need:
You violate constraint -> you get the explicit information on which and why and possibly a short guideline how to avoid it.

For current versions only "qualitative constrains" are guarded but all "quantitative constrains" are not because it is darn difficult to do that with current GCC binutils.

So at least if someone won't give me an idea how to solve it - I drop the ideas about solving "quantitative constrains" problem.