Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for ARM and ARM64 #446

Merged
merged 2 commits into from
Jan 30, 2023
Merged

Add support for ARM and ARM64 #446

merged 2 commits into from
Jan 30, 2023

Conversation

jeffkl
Copy link
Collaborator

@jeffkl jeffkl commented Jan 30, 2023

Fixes #437

@jeffkl jeffkl merged commit 771985b into microsoft:main Jan 30, 2023
@jeffkl jeffkl deleted the arm-arm64 branch January 30, 2023 21:50
@michael-hawker
Copy link
Contributor

michael-hawker commented Jan 30, 2023

Thanks @jeffkl!

Any thoughts on it still returning null and ignoring other values? This may matter on other platforms like Android/iOS, I know Uno Platform does stuff here in this space.

(Or at least maybe spit out some warning/info about it when it does occur?)

@jeffkl
Copy link
Collaborator Author

jeffkl commented Jan 30, 2023

Any thoughts on it still returning null and ignoring other values? This may matter on other platforms like Android/iOS, I know Uno Platform does stuff here in this space.

Can you elaborate more? What values would return null? At the moment SlnGen only emits stuff in the solution for configurations and platforms that it understands. From what I remember, this is what Visual Studio does if you use some custom values that it doesn't understand.

@michael-hawker
Copy link
Contributor

@jeffkl I can type anything in the Platform dialog:

image

I was also, previously to this commit, trying to pass ARM64 in:

dotnet slngen --platform "Any CPU;x64;x86;ARM64"

But that gets stripped by the null.

If there are custom tooling/msbuild sdks, etc... that may be used by a project, they may care about non-standard platforms, like the Uno Platform iOS ones:

image

@jeffkl
Copy link
Collaborator Author

jeffkl commented Feb 1, 2023

@michael-hawker this is extremely complicated from the command-line. Visual Studio has two concepts: Solution configuration and Project configuration. The hard part is mapping project configurations to solution configurations. When you use the UI, you get a nice grid and can create a solution platform and map it to the appropriate project platform. In some cases you'll want to create a solution configuration like "Custom Thing" but when you build it you want to map that to "x86" for the project.

Since SlnGen is a command-line tool, I haven't found a good way for a user to convey these mappings. At the moment, there are some built-in mappings for C++ projects, when you select a solution platform of Any CPU, it will build x86 or amd64 if the project supports one of those.

What works best is for the projects to convey what they support which is how SlnGen dynamically discovers configurations and platforms. If an SDK-style CSPROJ has:

<PropertyGroup>
  <Platforms>AnyCPU;x86;x64</Platforms>
</PropertyGroup>

Then SlnGen will generate a solution with the correct solution platforms and map it to the project platforms. What's missing is any way to convey a mapping. I'm not sure if its worth it at the moment but we could look into something like:

<ItemGroup>
  <SlnGenSolutionPlatform Condition="'$(Platform)' == 'x64'">MyCustomPlatform</SlnGenSolutionPlatform>
</ItemGroup>

But I'm not sure how many people need this functionality. In the 5 years that I've worked on SlnGen, no one has asked for custom mappings like this...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ARM/ARM64 not supported as values to --platform flag
2 participants