Config file for lessc - css

I need to override a lot of less variables.
I run less with script like
lessc --js --modify-var=#layout-body-background=#ffffff pathFrom > pathTo
But it is pretty painful write there all the variables to modify.
Is there a way to write some kind of config and run in something like
lessc --config=./pathToMyConfig

You can create a separate file called variables-overrides.less and in there you override all the variables you need

Related

Pass file containing values to modify less variables in the command line

I have a theme file ../styles/mytheme.less and I want to load it while compiling a less file in the command line, how do I include this?
Normal syntax is lessc --js --modify-var="primaryColor"="#ffeeff" main.less compiled.css
So in place of passing primary color, I would like to pass an entire less file of variables. Thanks.
use a batch file maybe? (not sure if this is what you are looking for)

Compiling all stylus files from given folder and its sub-folders

For example compiling this folder structure,
x.styl
|--abc/
|--|--a.styl
|--efg/
|--|--b.styl
To
build/
|--x.css
|--abc/
|--|--a.css
|--efg/
|--|--b.css
Using stylus compiler (compiling styl files from a folder and its subfolders)
You can use the --out parameter on building and target a whole folder, it will keep your structure, first you can target a file or folder, and after out the folder or filename you want to have your compiled css
stylus -c ./project/stylus --out ./myfolder/css
For:
|stylus
|--abc/
|--|--a.styl
|--efg/
|--|--b.styl
It would result in something like:
|css
|--abc/
|--|--a.css
|--efg/
|--|--b.css
A bit late on this, and I hope that might help others like it help me, but I found a solution using the package stylus-chokidar.
stylus-chokidar
Just slightly modified stylus CLI, that builds files list recursively and watches > them with chokidar (if --watch provided).
Recursion are always enabled, glob patterns not supported.
With this you can have the stylus files compiled in-place recursively (each component will store their own CSS/stylus files).
I am late on the game, but I believe I have a solution that is not optimal, but workable for your situation.
per your example, keep the same file/folder structure
x.styl
|--abc/
|--|--a.styl
|--efg/
|--|--b.styl
but also include a "combination.styl" file in its own separate folder. So now you have:
x.styl
|--abc/
|--|--a.styl
|--efg/
|--|--b.styl
|--all-stylus/
|--|--combination.styl
inside of combination.styl you should import all of the separate .styl files, so for our example
// combination.styl
#import '../x.styl'
#import '../abc/a.styl'
//etc...
then you can output one large css file wherever you would like!
the command to run this would simply be:
stylus ./stylus -out ./css
I know it doesn't give you the output file/folder structure you were looking for, but I imagine it is helpful to be able to compile all of your stylus into css at one time!

Sublime Text create SASS - Autoprefixer - CSS chain on save without Grunt

After watching Chris Coyer's
http://www.youtube.com/watch?v=M7W5unPM_b4&list=UUADyUOnhyEoQqrw_RrsGleA
I was wondering - is it possible to autorun Autoprefixer Sublime plugin right after the CSS file is built and without Grunt? What would I need to configure in Sublime and how?
Ideal chain would be:
Build compressed "style-unprefixed.css" on SASS save - run Autoprefixer - create compressed "style.css"
I'm no expert, but I think I just figured out how to do this, via a shell script.
Prerequisites:
SublimeOnSaveBuild (ST2 Plugin, also works on ST3)
SASS compiler (I'm using LibSass/SassC)
Autoprefixer (not the ST plugin)
After all that is taken care of, we'll create the script. For our purposes, let's call it buildcss.sh:
#!/bin/bash
if [ $# == 0 ]
then
echo "Usage: buildcss.sh [scss file] [css file]"
exit
fi
# Create the css file ($2) from a scss file ($1)
# see "sassc -h" for additional options
sassc $1 $2
# Run autoprefixer, overwrite input .css file
# see "autoprefixer -h" for additional options
autoprefixer -b "> 1%" $2
Of course if you're using Ruby SASS (sass) instead of sassc, the script should be adjusted.
Okay, at this step you should be able to run something like ./buildcss.sh style.scss style.css to test and make sure that part works. Then it's just a matter of making Sublime Text run that and pass the correct arguments.
For that, create a custom build system. Tools > Build System > New Build System... in ST3. There may be some differences between ST2 and ST3 here, but in ST3 my configuration looks like:
{
"shell_cmd": "/path/to/script/buildcss.sh $file ${file_path/scss/css/}/${file_base_name}.css",
"selector": "source.scss",
"line_regex": "Line ([0-9]+):",
}
As you may notice, I'm exclusively setting up for scss, but if you need sass you could set up another similar build system, exchanging "sass" for "scss" throughout. This build system also assumes that you keep your files in a /scss subfolder, and that css files should go in a /css subfolder at the same level.
And there you have it! Whenever you save a .scss file, SublimeOnSaveBuild will do it's magic and fire our custom build, which will in turn call the script which calls sassc and autoprefixer.

Automatically compile less css files in mac os x

I have started using less CSS.
I have written a small bash script which calls the "lessc" command with my target file and then pipes it into my finished css file. It looks something like this:
#!/bin/bash
lessc ~/Documents/Development/Projects/blog/static/css/global.less --watch > ~/Documents/Development/Projects/blog/static/css/styles.css -x
This -x flag compresses the CSS.
As you can see I have tried to use the --watch flag which from what I understood would mean it would automatically recompile the CSS every time you make a change to the less files. But this doesnt seem to work.
I realise I could use the "less app" that someone has written, but Im curious as to how to do this myself, as it's clearly possible.
Because less often uses #imports, it's an over-engineered solution to watch all the files involved. You can just use a simple loop to compile every so often, for example:
while true; do lessc bootstrap.less > bootstrap.css 2> /dev/null; sleep 5; done
If this is too simplistic, then you could try using the -nt test in Bash, which tests if a file's mtime is newer than the other, for example (supposing bootstrap.less contains an #import for custom.less):
while true
do
if [ bootstrap.less -nt bootstrap.css ] || [ custom.less -nt bootstrap.css ]; then
echo "Change detected, regenerating # $(date)"
lessc bootstrap.less > bootstrap.css
fi
sleep 5
done

Nmake getting a list of all .o files from .cpp files

I'm using nmake to compile multiple source files into an elf. However I do not want to specify the .o files in a long list like this:
OBJS = file1.o file2.o file3.o
What I would prefer is to use a wildcard that specifies all .o files in the current directory as dependencies for the .elf. However, the .o files don't exist until I've compiled them from the .cpp files. Is there any way to get a list of cpp files using wildcard expansion and then do a string replacement to replace the .cpp with .o.
There's not a particularly elegant way to do this in NMAKE. If you can, you should use GNU Make instead, which is available on Windows and makes many tasks much easier.
If you must use NMAKE, then you must use recursive make in order to do this automatically, because NMAKE only expands wildcards in prerequisites lists. I demonstrated how to do this in response to another similar question here.
Hope that helps.
I'm more familiar with Unix make and gmake, but you could possibly use:
OBJS = $(SOURCES:.cpp=.o)
(assuming your source files could be listed in SOURCES)
Here is another answer that might help you.
Another solution may be to use a wrapper batch file, where you create a list of all .cpp files with a "for" loop, like
del listoffiles.txt
echo SOURCES= \ >> listoffiles.txt
for %i in (*.dll) do #echo %i \ >>listoffiles.txt
echo. >> listoffiles.txt
Afterwards, you can try to use this with the !INCLUDE preprocessor macro in nmake:
!INCLUDE listoffiles.txt
(I am sure this won't work from scratch, but the general idea should be clear).

Resources