Mmp should log the destination file path when copying it to the bundle

[KirillOsenkov]

When Mmp is copying the files to the output bundle it should log the source and destination for each file copied, so people reading the MSBuild binlog can track down who copied the file.

I believe this logic is here:
https://github.com/xamarin/xamarin-macios/blob/a09a7d252352b207f794e7731d33b61667e34e13/tools/mmp/driver.cs#L1532-L1550

By default when MSBuild is copying files the convention is to use the Copying {0} to {1} message format (or Did not copy {0} to {1} because files sizes and timestamps matched).

It would be very helpful if we logged all file copies (including pdb, mdb, and config) using the above message format so one could just search the log for "Copying foo.dll" and find these. Right now it logs "Added assembly" and doesn't specify the destination path, so if you're searching for the destination path you won't find who logged it.

Additionally, we should consider switching Copied {0} to {1} to the same format ("Copying").
https://github.com/xamarin/xamarin-macios/blob/2b7dc07d20fc06344d7f164af8934f5e755572c2/tools/common/FileCopier.cs#L122

https://github.com/xamarin/xamarin-macios/blob/0924ce55efbd7170aa683ae9d4f694433a50b8d5/tools/common/Application.cs#L754

See also here:
https://github.com/xamarin/xamarin-macios/blob/a09a7d252352b207f794e7731d33b61667e34e13/tools/mmp/driver.cs#L1327

[spouliot]

Side notes:

• There's a lot of code shared between mmp (macOS) and mtouch (iOS, tvOS, watchOS and Catalyst);
• The tools do not exists in the dotnet world (only legacy) even if some code is reused between both toolchains;

When Mmp is copying the files to the output bundle it should log the source and destination for each file copied, so people reading the MSBuild binlog can track down who copied the file.

It's logged, but it might not be displayed, unless the verbosity is higher.

It's an old issue but getting the log verbosity from msbuild has been tricky (and the workaround, as I remember it, is not really perfect). IIRC that has to do with being able, for msbuild, to have multiple loggers (even if that's not the most common setup).

[KirillOsenkov]

We do pass -v -v -v -v which should be sufficient to see everything that's logged. Sample from binlog:

Sample Added assembly... message (note the destination is missing):

Sample Copied message (note it's not Copying like in MSBuild):

So searching for these is highly non-discoverable (also figuring out to pass -v -v -v -v to the tool as <MonoBundlingExtraArgs>-v -v -v -v</MonoBundlingExtraArgs> was highly non-trivial too.

[spouliot]

Added assembly... message

Agreed, that could be made easier to search across

So searching for these is highly non-discoverable (also figuring out to pass -v -v -v -v to the tool as -v -v -v -v was highly non-trivial too.

That part is what the msbuild verbosity sync should have fixed (maybe it was only in mtouch... or it got broken...I'll have to check). Ideally we would know (when invoked by the msbuild task) what level msbuild was told to log and would adjust our -v to match.

[KirillOsenkov]

For syncing with MSBuild verbosity this PR may be relevant:
dotnet/msbuild#6381

[rolfbjarne]

This isn't an issue in .NET anymore (we don't use mmp).