compiling on windows

[tkellen]

Hey Hampton!

I am hoping to get set up to provide Windows binaries for the node-sass project (for eventual use with the JS build tool gruntjs). There is some discussion about it @ sass/node-sass#10.

I develop on Mac, but I spun up a Windows VM today to give this a shot. I could well be doing something wrong, but here is what I turned up using Visual C++ Express 2010 on an x86 install of Windows 7:

------ Build started: Project: Sassc, Configuration: Debug Win32 ------
  sassc.c
c:\users\tyler\documents\github\sassc\sassc.c(11): error C2143: syntax error : missing ';' before 'type'
c:\users\tyler\documents\github\sassc\sassc.c(12): error C2065: 'ctx' : undeclared identifier
c:\users\tyler\documents\github\sassc\sassc.c(12): error C2223: left of '->options' must point to struct/union
c:\users\tyler\documents\github\sassc\sassc.c(13): error C2065: 'ctx' : undeclared identifier
c:\users\tyler\documents\github\sassc\sassc.c(13): error C2223: left of '->options' must point to struct/union
c:\users\tyler\documents\github\sassc\sassc.c(14): error C2065: 'ctx' : undeclared identifier
c:\users\tyler\documents\github\sassc\sassc.c(14): error C2223: left of '->input_path' must point to struct/union
c:\users\tyler\documents\github\sassc\sassc.c(16): error C2065: 'ctx' : undeclared identifier
c:\users\tyler\documents\github\sassc\sassc.c(16): warning C4047: 'function' : 'sass_file_context *' differs in levels of indirection from 'int'
c:\users\tyler\documents\github\sassc\sassc.c(16): warning C4024: 'sass_compile_file' : different types for formal and actual parameter 1
c:\users\tyler\documents\github\sassc\sassc.c(18): error C2065: 'ctx' : undeclared identifier
c:\users\tyler\documents\github\sassc\sassc.c(18): error C2223: left of '->error_status' must point to struct/union
c:\users\tyler\documents\github\sassc\sassc.c(19): error C2065: 'ctx' : undeclared identifier
c:\users\tyler\documents\github\sassc\sassc.c(19): error C2223: left of '->error_message' must point to struct/union
c:\users\tyler\documents\github\sassc\sassc.c(19): error C2065: 'ctx' : undeclared identifier
c:\users\tyler\documents\github\sassc\sassc.c(19): error C2223: left of '->error_message' must point to struct/union
c:\users\tyler\documents\github\sassc\sassc.c(22): error C2065: 'ctx' : undeclared identifier
c:\users\tyler\documents\github\sassc\sassc.c(22): error C2223: left of '->output_string' must point to struct/union
c:\users\tyler\documents\github\sassc\sassc.c(23): error C2065: 'ctx' : undeclared identifier
c:\users\tyler\documents\github\sassc\sassc.c(23): error C2223: left of '->output_string' must point to struct/union
c:\users\tyler\documents\github\sassc\sassc.c(29): error C2065: 'ctx' : undeclared identifier
c:\users\tyler\documents\github\sassc\sassc.c(29): warning C4047: 'function' : 'sass_file_context *' differs in levels of indirection from 'int'
c:\users\tyler\documents\github\sassc\sassc.c(29): warning C4024: 'sass_free_file_context' : different types for formal and actual parameter 1
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Do you have any advice on how to proceed? Also, thank you so much for all the work on sass, I'm stoked to start using it in JS projects.

[akhleung]

Not sure what the problem is yet. I'll be spending the next day or two working on cross-platform building.

[tkellen]

Heya Aaron, did you have any luck?

[akhleung]

Sorry, I don't have a Windows machine to develop on. I'll ask one of my colleagues who's recently been doing some Windows development. Sorry for the delay!

[QuLogic]

I think this may be caused by using the C++-ism of defining variables wherever you like. If you add struct sass_file_context* ctx; as the first line and change line 11 to remove the type (so it's just ctx = sass_new_file_context();), then I think that should fix it.

[goodtimeaj]

I'm attempting to compile sassc on Windows via cygwin. Has anyone done this? I'm getting undefined reference errors.

[akhleung]

I might as well ask the obvious: did you remember to pull in the libsass submodule?

[goodtimeaj]

Yes, the submodule is there inside the libsass dir. Is that what the error indicates? I am using cygwin but of course it's Windows and I noticed the paths in Makefile are using a forward slash. Also, the Makefile in libass/Makefile references "usr/local". Do you think this is a problem with the paths or is there some underlying problem with the compiler on Windows. Am I taking the wrong direction with using cygwin? If anyone has the latest compiled binary for sassc on Windows, please contact me.

[akhleung]

Some of my colleagues have used MinGW to compile a number of libraries on Windows (including LibSass, but not SassC). Maybe give that a try?

Sorry about not having better Windows support -- I don't have much experience with that platform!

[goodtimeaj]

I tried that too but got more errors - I'll try editing the paths. Still looking for anyone that can send me a compiled binary for Windows. Thanks, Aaron.

[SamHasler]

I have sassc successfully compiling on windows under msysGit. I had to download a couple of commands that weren't in msysGit but it works well enough.

[QuLogic]

@gregstallings: The sassc executable lives in the bin/ subdirectory. make sassc will attempt to compile sassc from sassc.o using a builtin rule and not anything in the Makefile. You need to do make bin/sassc or just plain make.

[goodtimeaj]

@SamHasler glad to hear msysgit worked. I'll try that.

[normadize]

I believe sassc has the potential of making SASS a lot more popular. The majority of people I know, especially the ones on Windows, are put off by SASS just because of Ruby alone. Even though I'm a dev myself, I also refuse to install Ruby just for SASS so I'm trying to get sassc to work on Windows.

I successfully compiled sassc on all of these: MinGW, Cygwin and MsysGit. The keyword here is compiled because they fail on syntax errors in the .scss file. Only the MsysGit (with some precaution) worked for me.

Note that it is of interest for sassc to also work if executed from outside these environments, i.e. from a raw Windows console or when called externally by an IDE. In that case, either place sassc.exe in the bin directory of those environments (next to required DLLs) or include those bin folders in PATH. Regardless of how I tried it, the MinGW and Cygwin compiled binaries still failed as per below.

MinGW: If there is any syntax error in the .scss file, then sassc.exe crashes spectacularly and outputs nothing about the .scss syntax error or line number, like the Linux version does. See screenshot:

https://www.dropbox.com/s/93tnih5wy468kit/screen-20130310-001.png

This happens both if the bin mingw folder is in PATH (the std C DLL is needed) or if the sassc binary is copied in the bin folder.

This is odd since MsysGit (which works, see below) also uses MinGW, but an older version of it. The minGW distro I'm usin gis based on gcc 4.7.2 while MsysGit is using MinGW based on gcc 4.4.0.

Cygwin: The Cygwin binary is less spectacular but not much more helpful. It crashes in the console, not with a pop-up window, but still nothing about the .scss having syntax errors:

bin\sassc.exe style.scss
Aborted (core dumped)

Again, it didn't matter if the Cygwin bin was in PATH or if the sassc binary was copied in bin or whether it was executed from within Cygwin's bash or externally (I need it inside my IDE so Cygwin bash is not an option for me anyway).

MsysGit. This is the only one that worked fine, provided I removed all bin folders of MinGW or Cygwin from PATH (which in my case created conflicts). If you take care of that, then it works fine:

$ bin\sassc style.scss 
ERROR -- style.scss:46: body for mixin asdas must begin with a '{'

MsysGit also embeds all libraries in the sassc binary so you don't need to carry the std C DLL with it or to place sassc in some folder where it exists ... but this is just a matter of configuring the compiler and linker options.

Linux: On Linux, sassc works just fine:

$ ~/sassc/bin/sassc style.scss 
ERROR -- style.scss:46: body for mixin asdas must begin with a '{'

Hopefully this helps other people .. this was the first thread I got in Google when searching about compiling sassc on Windows.

[QuLogic]

This happens both if the bin mingw folder is in PATH (the std C DLL is needed) or if the sassc binary is copied in the bin folder.
Again, it didn't matter if the Cygwin bin was in PATH or if the sassc binary was copied in bin or whether it was executed from within Cygwin's bash or externally (I need it inside my IDE so Cygwin bash is not an option for me anyway).
MsysGit also embeds all libraries in the sassc binary so you don't need to carry the std C DLL with it or to place sassc in some folder where it exists ... but this is just a matter of configuring the compiler and linker options.

Given that you need to mess with the PATH and you seem to have all three of Mingw, Cygwin, and MsysGit installed, it seems very much like you've compiled against one set of DLLs and ran with a different set. Especially since you say MsysGit links things statically and it works.

I would get each of them to compile statically. Or fix up the PATH and such so that only one of them could ever conceivably be used at one time before compiling at all.

[normadize]

Of course I took care to compile individually with no conflicts -- PATH was cleaned before compiling in each. I was talking about what to do with the executable afterwards (Cygwin and MinGW need the msys and stdC DLLs). What I posted above holds, at least for me, you can try it. I could only get the MsysGit version to run correctly.

[georgiosd]

I can confirm that compilation on Windows with msysgit (full 1.9.3) works as simple as fetching the repo and doing "make"

[HamptonMakes]

So sassc itself isn't meant for windows, as it's a unix command line util
wrapper. libsass itself does compile on windows. Node-sass doesn't use
sassc and is a wrapper on libsass. See if you can compile libsass by itself
on windows...

On Thursday, June 27, 2013, Georgios Diamantopoulos wrote:

I can confirm that compilation on Windows with msysgit (full 1.9.3) works
as simple as fetching the repo and doing "make"

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-20104360
.

[georgiosd]

It compiles ok for this guy: https://github.com/TBAPI-0KA/NSass
On this occasion I needed an executable compiler instead of a library

[am11]

Compiling current libsass with VS2013 Update 3 (express, professional etc.) is possible. This is how node-sass' build system is configured (using node-gyp, which uses VS2013). For sassc, it would require two safe guard header.

Perhaps you can find the .vcxproj file useful: https://github.com/darrenkopp/libsass-net/tree/master/libsass.

Also, see this discussion: sass/libsass-net@94abbd7#commitcomment-8333599.

(this repository can have either nmake or vcxproj file of its own, to make it easy to compile with MSVCR's cl.exe)

[am11]

Guys take a look at https://github.com/darrenkopp/sassc-win/.

There we have VS2013 solution for sassc and libsass.

Also appveyor is configured to run sass-specs tests on Windows via sassc-win: https://ci.appveyor.com/project/darrenkopp/sassc-win/. Comparing with Travis-ci, the results are ditto at the moment. :)

[hon2a]

Compilation on Windows fails for me as well. I tried to use this instead of Ruby+Sass to avoid the need for Ruby. I compiled it in current MinGW (GCC 4.8.1; had to change -std=c++0x to -std=gnu++0x in libsass makefile) and wrote a shell-script adapter to translate command-line parameters from original Sass syntax. Then I found it to fail spectacularly, as described above (crashes with This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. text & popup).

I've got no more time for experimentation, so I'm installing Ruby. Pity.

[am11]

BTW, to build libsass on WindOS, you don't need CYGWIN or MinGW. VS' free community version (for OSS devs) will do the job. Please see this: sass/libsass#648 (comment).

[hon2a]

@am11 If I'm to choose between installing Visual Studio and installing Ruby, I think I'm gonna go with Ruby :)

[am11]

Considering libsass has performance edge over Ruby sass, someone might go with different route here. :)

[mgreter]

Closing this since we now have appveyor testing the build via mingw and visual studio 2013 on windows!