Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Library that is platform-specific via selective compilation?
The proposed library would sit alongside cross-platform libraries in Xamarin apps for iOS and Android. However, it would include files with names like
MyLibraryFile.android.cs
MyLibraryFile.ios.cs
Each file would have platform-specific content, and all files would be visible in the solutions for each platform, i.e. in the solution for the Android app, under MyLibrary, you would also be able to see MyLibraryFile.ios.cs.
The contents of the library would be steered via the project file, which would have a structure as follows.
First, a list of target frameworks is set
<PropertyGroup>
<TargetFrameworks>Xamarin.iOS10</TargetFrameworks>
<TargetFrameworks Condition="'$(OS)' != 'Unix'">$(TargetFrameworks);MonoAndroid12.0</TargetFrameworks>
</PropertyGroup>
Then, the project file selects which .cs files to build based on the TargetFramework set in the app project.
<ItemGroup Condition="$(TargetFramework.StartsWith('MonoAndroid'))">
<Compile Include="**\*.android.cs"/>
</ItemGroup>
My question is, is this a recognised pattern?
I can't find anything about it.
1 answer
The general mechanism you describe has been in use since there were cross-compilers and libraries that were meant to provide the same application interface on different platforms. Your specific example using XML is newer of course.
Any competent build system has the ability to switch include files and make other modifications based on the target platform. This is nothing new.
One of the earliest full build systems (and source code control too) that I am aware of was Apollo DSEE, developed in the early 1980s. In DSEE, you specified the target platform via selecting a "thread". The various build files could cause different files to be used and command line options changed based on state ultimately derived from the thread.
Before that, people used shell scripts to achieve the same thing, although not as elegantly as full-blown build systems.
This is an ancient concept, probably because it's an obvious solution when faced with the multi-platform build problem.
0 comment threads
1 comment thread