Proposal: Change the way of building native binaries

[am11]

Currently we are compiling both x64 and x86 libsass binaries (solution) build.

This needs to change in such a way that we compile only one binary for the given set of configuration with constant name (libsass) and avoid copying binaries around.

This will help us when we build against other platform such as Linux and OSX.

node-sass has also this way of compiling one binary per build.

---

@darrenkopp,

This is the first step towards .NET Core support.

NuGet packaging would be also easier for multiple operating system, as it requires the same name but create the OS+Arch specific directory. Note that there is a platform inheritance involved in latest NuGet packaging when dealing with native binaries. For instance, Alpine Linux x64 inherits Linux x64, which has a sibling Linux x86 and parent Linux, which has Unix as parent and OSX and FreeBSD etc. at sibling nodes. NuGet handles all this at restore time, if we follow the right convention to package the bins.

I have few ideas about packaging that I would like to try once we get there. :)

Thoughts?

[nschonni]

I was thinking about this yesterday when I was trying to build. What about just getting rid of the "AnyCPU" target and then just include the VC++ project directly? Still requires more than one build for full packaging, but builds quicker.

[darrenkopp]

@nschonni That's how it did it in the past, but it really makes the nuget packaging story pretty painful for downstream libraries that then had to split their packages into x86/x64 versions as well.

[nschonni]

Fair enough, looking at https://www.nuget.org/packages/Microsoft.TeamFoundationServer.ExtendedClient looks like they still use a native folder under lib along with the target architectures.

[am11]

@nschonni, I guess TFS package might not be the good example as it is tied to Windows and only supports full .NET Framework. For example, compare the Dependencies section to a real cross platform, multi-framework package: https://www.nuget.org/packages/System.IO.Compression/.

Speaking of which if we search for S.IO.C: https://www.nuget.org/packages?q=System.IO.Compression we will find sea of packages starting with runtimes.. Few new concepts introduced in nuget lately, one of them is transitive dependency. In this case, S.IO.C will install S.IO.C package (with managed assemblies only), then runtime.<platform>.S.IO.C package which will include common assemblies for this platform (say win7), then runtime.<platform>-<architecture>.S.IO.C for x64 etc., then runtime.<platform>-<version>-<architecture>.S.IO.C for this version of platform and finally runtime.<platform>-<version>-<architecture>.<dotnetRuntime>.S.IO.C where dotnetRuntime could be aot (ahead of time), native (.Net Native) etc.

There is a well defined convention to get all this packaging done automatically by Nuget and then Nuget resolves the dependency from most specific to most general at restore time based on the target's RID (runtime ID). For example, like node-sass if we build Linux binary on CentOS, then we don't need to specialize RID for Fedora and MintOS etc. But in case of Alpine Linux, we would want to create a separate package as Alpine uses musl-libc instead of glibc etc.

A lot of stuff that we were doing by hand in node-sass is handled by the latest Nuget (v4 is in RC stage), just need to follow few conventions (basically by mimicking how they are handling stuff in CoreFX, SDK and Core-Setup repos of dotnet organization). :)

[nschonni]

Makes sense, I'm looking at the base build right now since it's not compiling for me. I won't try anything to do with Core though 😉

[am11]

Lol, I just wanted to have general feeling whether building for current-platform-only based on solution configurations. will submit a PR today or by tomorrow. :)