Skip to content

Fix FastFetch build in VS for Mac#1060

Merged
wilbaker merged 2 commits intomicrosoft:masterfrom
wilbaker:fix_ff_build_on_mac
Apr 24, 2019
Merged

Fix FastFetch build in VS for Mac#1060
wilbaker merged 2 commits intomicrosoft:masterfrom
wilbaker:fix_ff_build_on_mac

Conversation

@wilbaker
Copy link
Member

The ItemGroup conditions are not working properly in VS for Mac (I noticed this reported on StackOverflow for VS 7.5.3 and so we don't appear to be the only ones having this issue).

To work around this limitation I've switched the project to use. Choose/Where

Use Otherwise for Mac in FastFetch csproj
@nickgra
Copy link
Member

nickgra commented Apr 23, 2019

In the Stack Overflow post, I don't see a link to an issue in VSMac for this. Should we open an issue on their side (in monodevelop?) for this to track removing this workaround?

@wilbaker
Copy link
Member Author

Should we open an issue on their side (in monodevelop?) for this to track removing this workaround?

That's a good idea, do you know where I can submit an issue to them?

@nickgra
Copy link
Member

nickgra commented Apr 23, 2019

Should we open an issue on their side (in monodevelop?) for this to track removing this workaround?

That's a good idea, do you know where I can submit an issue to them?

Historically, we've filed issues directly in their Github issues (see: mono/monodevelop#4837). This also seems like a 'Project Model' issue to me.

Copy link
Member

@nickgra nickgra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved with suggestions.

Thanks for getting to the root cause of what was actually broken here!

</When>
<Otherwise>
<ItemGroup>
<ProjectReference Include="..\GVFS.Platform.Mac\GVFS.Platform.Mac.csproj" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whenever Linux comes online, is there a way we can rework this code to keep VSMac working but load the Linux platform instead of the Mac one?

Copy link
Member Author

@wilbaker wilbaker Apr 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whenever Linux comes online, is there a way we can rework this code to keep VSMac working but load the Linux platform instead of the Mac one?

I found that the conditionals did work when using the build script, and so I suspect we could do something like:

<When Condition="'$(OS)' == 'Windows_NT'">
    // Windows stuff
</When>
<When Condition="'$([System.Runtime.InteropServices.RuntimeInformation]::IsOSPlatform($([System.Runtime.InteropServices.OSPlatform]::Linux)))' == 'true'">
    // Linux stuff
</When>
<Otherwise>
    // Mac stuff
</Otherwise>

I was also discussing this with @jamill a bit and it would be nice if the condition was driven by the active configuration (e.g. Debug.Windows|x64) rather than the current platform that we're building on. So far I have not figured out how to do that, do you know if it's possible?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Frankly, your proposed approach does not look too bad to me so long as we leave a comment on why it's like that.

So far I have not figured out how to do that, do you know if it's possible?

I have not seen any documentation that indicates picking up the active configuration is possible, although it would be very useful :) Even if it's supported on Windows, I wouldn't trust the VSMac .csproj parser to understand it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a bit of searching on this, but could not find a great solution for controlling this via the solution configuration.

One thing I was considering:

  1. Could we define a property in GVFS.props that specifies which target OS we are building for, and put all the logic for detecting this in there? That way, all other projects could key off the value of this property. (e.g. TargetOSPlatform or something?

  2. While not accessible from the IDE, we could build for a specific platform from MSBuild (or dotnet build) via /p:TargetOSPlatform=macOS or /p:TargetOSPlatform=Windows..., or possibly via an environment variable?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so long as we leave a comment on why it's like that.

Comments added!

Could we define a property in GVFS.props that specifies which target OS we are building for, and put all the logic for detecting this in there?

I think that sounds good. If/when we need to add checks like this in a second project we should see if we can get this logic in a common spot.

we could build for a specific platform from MSBuild (or dotnet build) via /p:TargetOSPlatform=macOS or /p:TargetOSPlatform=Windows..., or possibly via an environment variable?

It looks like we're pretty close to this today:

Windows

SET SolutionConfiguration=%Configuration%.Windows

%msbuild% %VFS_SRCDIR%\GVFS.sln /p:GVFSVersion=%GVFSVersion% /p:Configuration=%SolutionConfiguration% /p:Platform=x64 || exit /b 1

Mac

dotnet build $VFS_SRCDIR/GVFS.sln --runtime osx-x64 --framework netcoreapp2.1 --configuration $CONFIGURATION.Mac -p:CopyPrjFS=true /maxcpucount:1 /warnasmessage:MSB4011 || exit 1

Fortunately the command line builds haven't had any issues, it's been with the VS for Mac IDE specifically.

@wilbaker
Copy link
Member Author

Historically, we've filed issues directly in their Github issues (see: mono/monodevelop#4837). This also seems like a 'Project Model' issue to me.

Thanks! I've filed mono/monodevelop#7417 for this.

@wilbaker wilbaker merged commit 6d8c8de into microsoft:master Apr 24, 2019
@wilbaker wilbaker added this to the M152 milestone Apr 24, 2019
@jrbriggs jrbriggs modified the milestones: M152, M151 May 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants