Libsass: Problems getting libsass to compile on windows

You had me at pizza. But seriously I'm excited to see this happening in sprockets. @am11 as our resident Windows expert do you have any ideas what could be happening?

msbuild win/libsass.sln

If you are sure that this MSBuild in PATH corresponds to version of VS you have installed (i.e. by running msbuild /version), then this command is sufficient to build LibSass in Debug configuration. Passing /p:Configuration=Release to the command will build the shared lib in Release configuration. You can also try by invoking MSBuild with absolute path as per the build doc: https://github.com/sass/libsass/blob/master/docs/build-with-visual-studio.md#from-powershell

If you are still having the same issue, then Google returns a following workaround for error code, TRK0005:
https://blogs.msdn.microsoft.com/deva/2015/03/24/after-migration-vs-2013-c-project-throws-error-trk0005-failed-to-locate-cl-exe-the-system-cannot-find-the-file-specified/

BTW, for the local build box to test out windows status etc.; if you don't want VS, you can just have Build Tools for VC installed to compile C/C++ projects strictly via command line -- with absolutely no glorious GUI: http://landinghub.visualstudio.com/visual-cpp-build-tools

Just getting to this comment now. I'm going to give this a shot. Thanks a ton! Will keep issue updated.

Also thanks for the windows support in the first place. It's a huge responsibility and the few times i've had to make windows compat patches makes me grateful for anyone who has experience there.

As a side note it looks like the makefile has some window specific code in it: https://github.com/sass/libsass/blob/6610e815ff77600fedf22bf10541d08d70f94218/Makefile#L26-L42 did this file work with nmake at one time?

Hello, regarding the side note: I think that code was meant for MinGW/Cygwin Makefile support and @mgreter can probably confirm it. nmake Makefile is a different entity and is most probably still shipped just to support the ancient projects. MSBuild was introduced as a "modern" build system, therefore we put effort to support that XML format.

We can probably switch to CMake at some point to encapsulate the underlying build systems. However, a handwritten Makefile and vcxproj files was preferred initially, but if it is causing effort for downstream consumers, we should look into CMake. @mgreter has put some major effort in the build system area.

I am on vacation and refraining myself to go near computers for six more days.. but yet here we are! 😄 I will try to catch-up with sprockets development and contribute. I used this gem back in the days with Rails 2x and glad to see it still standing tall. Thanks for your efforts @schneems! 👍

Hey, i'm trying to refrain from posting due to vacation (I really wish github had an OOO or Do not Disturb feature). Don't worry about replying while away.

Your advice was great and worked, also I found this doc https://github.com/sass/libsass/blob/master/docs/build-on-windows.md (way too late) which did re-confirm many things you've told me. I got a build working and I believe i've linked to it correctly using Ruby FFI interface, i'm now getting a segfault when I call into the lib. It could be a problem with the Ruby FFI interface, a problem with the sassc-ruby glue code, or a problem with the build of libsass into a dll.

I don't think you should need to know anything about Ruby, but maybe you could help with that last one. Is there any way for me to verify the dll I made works or is valid?

Let me know when you get back, hope you're enjoying time off.

@schneems good to hear things are getting better. Thanks for providing all the information needed to troubleshoot this in your pull request - this is very useful. Can you try using MinGW toolkit to build libsass instead of Visual Studio? I've left the comment at the appropriate place.

@schneems, I just found DevKit documentation: http://github.com/oneclick/rubyinstaller/wiki/Development-Kit and the fact that it is based on MinGW.

I then installed Ruby 2.3.0 and DevKit on my local VM, then added C:\tools\ruby23\devkit\bin and C:\tools\ruby23\devkit\mingw\bin in PATH.

After that, I applied the following diff on top of https://github.com/schneems/sassc-ruby/commit/85ed6730341c18b9e700a6e717be84461389fdc4:

diff --git a/lib/sassc/native.rb b/lib/sassc/native.rb
index 261daba..b52b0c2 100644
--- a/lib/sassc/native.rb
+++ b/lib/sassc/native.rb
@@ -6,12 +6,7 @@ module SassC

     spec = Gem.loaded_specs["sassc"]
     gem_root = spec.gem_dir
-    if RUBY_PLATFORM =~ /mswin|mingw/
-      libsass_path = "#{gem_root}/ext/libsass/win/bin/libsass.dll"
-    else
-      libsass_path = "#{gem_root}/ext/libsass/lib/libsass.so"
-    end
-    ffi_lib libsass_path
+    ffi_lib "#{gem_root}/ext/libsass/lib/libsass.so"

     require_relative "native/sass_value"

diff --git a/lib/tasks/libsass.rb b/lib/tasks/libsass.rb
index 3542d8f..e439820 100644
--- a/lib/tasks/libsass.rb
+++ b/lib/tasks/libsass.rb
@@ -20,7 +20,7 @@ namespace :libsass do
     make_program = ENV['MAKE']
     make_program ||= case RUBY_PLATFORM
                      when /mswin|mingw/
-                       'msbuild /m:4 /p:Configuration=Release win/libsass.sln'
+                       'make lib/libsass.so'
                      when /(bsd|solaris)/
                        'gmake lib/libsass.so'
                      else

When I executed $CC="gcc" ; bundle exec rake test in PowerShell on Windows 10 x64, it passed:

Run options: --seed 1950

# Running:

********************************S*************************

Fabulous run in 0.174091s, 333.1591 runs/s, 539.9475 assertions/s.

58 runs, 94 assertions, 0 failures, 0 errors, 1 skips

I think your AppVeyor script would not need any alteration. _Maybe_ you would need to add CC like this:

environment:
  global:
    CC: gcc
  matrix:
  ..

@schneems does the info by @am11 above resolve your issue?

Sorry for the delay. I keep getting pulled away from this project. I'm going to close this for now so it doesn't clog up your issues. Thanks for the help. I hope to return to this soon.