visual studio -- solution file fixer task

[Fred T. Hamster]

got up to notes 12 on this at legacy farm.

implementation notes:

+ extract refs from proj file (remove them) that we'll replace.

+ push the new refs we calculated into the file.

+ still need an extractor for the GUID; we will need the GUID for a project

when we build a reference for it. guid is in: ProjectGuid

+ note that we're not generating a complete list of refs needed--just the list

of refs implied by c++ libs used in the project.
+ we should only add the references that are not there yet.

--
problem seen in projects:

fixer thing would be place to fix it maybe...
apparently if header files are listed that do not exist,
a bug in visual studio can make them be recompiled.

--

===============

proof of concept:

all the core libraries should already be right.

but the ones in shared no longer have their dependencies down to the core stuff.

those shared libs need their proper core deps.
then we should be able to remove the core prereq deal entirely.

once this is done, the proof is this:

you can build release or debug version of shared solution, and:

1) the core stuff all gets built in the same matching way,
2) nothing fails or gets weirdness.

---

can we ignore references to c# stuff? those won't build if they're not correct,
right? so, we are mainly trying to fix the visual studio stuff, where it could build
right but have wrong references or dependencies.
=> we think we can ignore c# for now.

so, we need functions to:
DONE: extract created asset from a project file (x.dll etc)
DONE: extract the file name from a project reference.
DONE: turn an absolute path into a path relative to a project file location
DONE: extract GUID from a project file.
DONE: extract libraries used by a project

DONE + so some form of parsing refs is needed but it could be really simple.

DONE + yes, the project FILE name is provided in the ProjectReference line.

===============
DONE: to really do this right we need a tool that can fix a project.
if the project says, i need libs X, Y, and Z.
the tool should:

locate projects for X, etc where can.
include reference chunks for those projects.

done
===============
DONE:
tool for adding refs:

extra projects seems to work at getting what references are ALREADY there.
we need to know which ones aren't.
AdditionalDependencies has two flavors--one for debug and one for release.

we could probably use the first one encountered, since these *should* be the same.

given that list from additdeps, we know the dlls needed by the project (strip lib off

the ending to find the dll name).

using these names, we can expect that project files to exist with same name;

and we'd be disappointed since there are some where they don't match.
firmware api for example.

although, we could actually do a pre-search to find all the products of all our projects.

then we would have a complete list of who builds what,
and could reason using the right names.
we also then wouldn't have to search for anything; it's already computed.

===============

DONE: + current high priority:

get the thing to generate the list of references *needed* for a project.
just show the list; we can do spooning it into proj files next.

AINTGONNADO: + if we have a manifest of all the projects in hierarchy, it would be easy to fix

wrong paths in existing refs.

=> i think we have that now. check?
=> this is not super important though; it's not a generalized fixer, but more of a

thing to ensure your c++ stuff is hooked in right. for one thing, it won't currently
fix missing refs, since that would require reading the code and finding who wasn't pulled in.
we're not the slightest bit working on that, so we can't fix refs in general either.

ALSO NO: + we should fix references with wrongful paths?

yes, find all refs for things we already know about (which we can fully
replace a reference for) and whack them.
this is <ProjectReference>.*pathjunk\the_name_in_question.vcxproj (e.g.)

...</ProjectReference>

so the whacking is based on whether we have decided that they need the
project file there.