On Tue, 30 Oct 2012, Jonathan M Davis wrote: > On Tuesday, October 30, 2012 01:45:31 bearophile wrote: > > Andrei Alexandrescu: > > > Why can't the linking code be built into dmd? I am baffled :o). > > > > This is possible, but a better question is how much work is > > required to do this? > > > > Walter was very slowly translating the current linker from > > disassembly to C. If and once that program is all C, it's > > probably not too much hard to convert it to D, merge it with the > > dmd binary, and improve it in some ways. > > Depending, it should be fairly easy to just wrap the linker call and have dmd > process its output and present something saner when there's an error. That > could be a bit fragile though, since it would likely depend on the exact > formatting of linker error messages. Better integration than that could be > quite a bit more work. > > I think that it's fairly clear that in the long run, we want something like > this, but I don't know if it's worth doing right now or not. > > - Jonathan M Davis If someone wants to work on it, I'm sure no one would stop them. In fact, someone did a specific case already.
But for the Top Men to engage on? Almost certainly not. I was working on "recognize that there's room for improvement" and "improvement is important for adoption" not "get working on it now". -- If someone wanted to take on an ambitious task, one of the key problems with output munging is the parseability of the output (which applies to the compiler, linker, etc.. all the compiler chain tools). Few (none?) of them output text that's designed for parsability (though some make it relatively easy). It would be interesting to design a structured format and write scripts to sit between the various components to handle adapting the output. Restated via an example: today: compiler invokes tools and just passes on output ideal (_an_ ideal, don't nitpick): compiler invokes tool which returns structured output and uses that intermediate that's likely easier to achieve: compiler invokes script that invokes tool (passing args) and fixes output to match structured output pro: + compiler only needs to understand one format + one script per tool (also a con, but on the pro side, each script is focused in what it needs to understand and care about) + no need to tear into each tool to restructure it's i/o code cons: - will likely force some form of lowest common denominator - more overhead due to extra parsing and processes I used the term script, but don't read much into that, just implying that it's small and doesn't have to do much. Now that I've written it up.. might actually be fun to do, but I've got too many in-flight projects as it is, so I'll resist starting on it. Later, Brad
