@bolandrm need your help on this one.

#238 fixes this.

@bolandrm or anyone, can you please help on this? Is this gem still maintained?

@johnnyshields As mentioned in #239 and #220 (based on my own research), it might be reasonable to consider this as dead. Work seems to have migrated to dart-sass and given libsass is deprecated, which is at the core of this gem I suppose it doesn't have a big reason to exist, longer term.

As referred to by others in #220, I have had great success moving to https://github.com/ntkme/sassc-embedded-shim-ruby to thus depend on dart-sass with minimal changes and no need to compile dependencies or worry about platforms (and still being able to use sprockets/rails which was useful in my particular case), which I'd encourage you to have a look at. Can see an example of a migration at gocd/gocd#10794 if it's useful (JRuby project, but still).

@chadlwilson thank you for the reply. Would you be willing to let me/my company take over on extended life maintenance, as there are quite a few people out there still using it and and wanting to upgrade to latest Ruby etc releases?

@johnnyshields I'm not a maintainer - just another community user sharing my experience. 😉 Happened to be subscribed to this issue as I was also struggling trying to build libsass on Windows as well earlier.

I subsequently discovered the sassc-ruby shim to delegate to sass-embedded which completely avoids such compile or gem platform problems as it downloads pre-built binaries for the relevant platform on the fly during gem install.

Of course it's OSS, so you are free to fork; but given the underlying libsass has been deprecated for two years and doesn't seem to have seen much development in the last 18 months, you might have to fork that too... and personally I think you might be better to put the effort in to migrate to something based on dart-sass rather than taking on the maintenance burden of possibly not just this, but also its relationship with libsass. Just my 2c - obviously you can evaluate what's best for your situation.

if we could do a major release here and integrate the work from https://github.com/ntkme/sassc-embedded-shim-ruby that would be ideal as we don't have to update all gems that depend on this one... but if that is not the path here, sass-contrib/sassc-embedded-shim-ruby#25 should decouple from sassc-ruby all together and we can move further.

having newer sass available through ruby API again could help update projects like sprockets which is still a dependency in many others.

IIRC @ntkme enquired about possibility of that somewhere in sprockets-land I believe. IMHO it's reasonably well decoupled in that most of the work happens in https://github.com/ntkme/sass-embedded-host-ruby and the repo you linked to is purely just a shim that redirects away from libsass.

And then there's dartsass-rails. The shim allows continued use of sprockets in the lightest touch way possible.

Maybe rails/sprockets#661 was what I was thinking of.

The problem with the approach is that you need to override sassc with a git repository. This makes deployment a bit harder and slower. Ideally we would either solve here or do a real fork that can be used moving further.

This doesn't dismiss the benefit of existing solution which can act as a bridge and help people migrate from one solution to the other.

But consider that anyone building something that should rely on sassc would be better served with a version/fork that works without requiring extra hacks

This is the way: #240