I use lessc 2.7.3. I generate css files via a makefile and use following paths
the makefile is in themes/bodensee
the css is generated in themes/bodensee/css
the less files are in themes/bodensee/less
the maps are in the same folder as the css files.
My problem is that css files misses the themes/bodensee path, so it raises a file not found on css.map files.
lessc -s less/wlb.less --clean-css="--s0 --advanced" --source-map-rootpath=themes/bodensee/ --source-map="css/wlb.css.map" css/wlb.css
The CSS file now contains `sourceMappingURL=css/wlb.css.map``The rootpath does not have any effect.
I also tried a fantasy rootpath and searched for it in the file - it does not appear anywhere. But the option is correct. When I try to missspell the option, LESS drops an error.
What am I missing?
Description of the --source-map-rootpath option from here
Specifies a rootpath that should be prepended to each of the less file paths inside the sourcemap and also to the path to the map file specified in your output css.
Because the basepath defaults to the directory of the input less file, the rootpath defaults to the path from the sourcemap output file to the base directory of the input less file.
Use this option if for instance you have a css file generated in the root on your web server but have your source less/css/map files in a different folder. So for the option above you might have
The problem was indeed related to the Clean-CSS plugin.
I now call
lessc --source-map --clean-css="--s0 --advanced" -s less/wlb.less css/wlb.css which is working.
There is a standalone clean-css program, but that does not generate sources for the Less files. It's not clear if the lessc plugin and the standalone tool are the same or different implementations but both use node.
The standalone cleancss tool removes the source map URL generated by lessc be default (did not play around with the dozens of options).
These Node tools develop very fast and manual/tutorials often are outdated. That's why my make file stopped working. Developers of that tools should really consider not to touch working parameters or features and to keep their code compatible.
Related
Question
When building Singularity images using definition files, is there a way to specify the path to a file on the host system relative to the definition file (i.e. independent of where the build command is called)?
Example to Illustrate the Problem
I have the following files in the same directory (e.g. a git repository):
foobar.def
some_file.txt
foobar.def looks as follows:
Bootstrap: library
From: ubuntu:20.04
Stage: build
%files
# Add some_file.txt at the root of the image
some_file.txt /some_file.txt
This works fine when I build with the following command in the directory which contains the files:
singularity build --fakeroot foobar.sif foobar.def
However, it fails if I call the build command from anywhere else (e.g. from a dedicated "build" directory) because it searches some_file.txt relative to the current working directory of the build command, not relative to the definition file.
Is there a way to implement the definition file such that the build works independently of where the command is called? I know that I could use absolute paths but this is not a viable solution in my case.
To make it even more complicated: My actual definition file is bootstrapping from another local image, which is located in the build directory. So ideally I would need a solution where some files are found relative the working directory while others are found relative to the location of the definition file.
Short answer: Not really
Longer answer: Not really, but there's a reason why and it shouldn't really matter for most use cases. While Docker went the route of letting you specify what your directory context is, Singularity decided to base all of its commands off the current directory where it is being executed. This also follows with $PWD being auto-mounted into the container, so it makes sense for it to be consistent.
That said, is there a reason you can't run singularity build --fakeroot $build_dir/foobar.sif foobar.def from the repo directory? There isn't any other output written besides the final image and it makes more sense for the directory with the data being used to be the context to work from.
I am installing a package manually on my own system because I need to make some changes to it that aren't available in the basic version in my package manager. I also am trying to keep packages installed locally if possible, so I'm installing it with prefix=$HOME/.local instead of the more common prefix=/usr/local.
When I do this, I have no problem executing the program from my terminal, because I added ~/.local/bin to my PATH and the package was installed with relative paths to its shared libraries (i.e. ~/.local/lib/<package>). Executing from the command line is no problem, but I want to be able to access it from the favorites menu in gnome, and for that I need to make use of the <package>.desktop file.
I could hard-code the path to the executable in the .desktop file itself, but when I pull a later version down and re-install it, I'll have to redo those steps. I was wondering if there's a way to avoid that.
I've tried symlinking the executable to a directory where .desktop files do have included in their path, and the application is correctly treated as a GUI option, but launching the executable results in an error trying to find a shared library. I think this has to do with how cmake handles rpaths, which to my understanding is a way of relatively linking executables with their required libraries.
I think what I want to do is have PATH inside a .desktop file include ~/.local/bin, without changing the .desktop file itself. Can I alter the 'default' path used in accessing a .desktop file?
The answer to my question was found in the Archwiki:
Specifically, I needed to add ~/.local/bin to my path in ~/.xinitrc. Now my graphical programs work as expected.
Bottom line I need lessc to compile my main.less file to $CATALINA_EC_TMP/main.css
I'm working on this project, where I need to generate multiple output css files originating from the same source (LESS file) using LESSC.
So with Jet Brain's (WebStorm or IntelliJ Idea) File Watcher, I don't get much of options to save the output files to a custom path using an environment variable.
The reason why I use an environment variable is because some of the outputted files is in a temporary path (it changes whenever I deploy with ant)
That said ...
This is my Environment Variable:
$CATALINA_EC_TMP = '/foo/bar/'
and it's changing so in the next deployment, it won't be /foo/bar/ anymore.
and this is the command line that's being executed by my IDE to compile less files
/usr/local/bin/lessc --no-color main.less
I need lessc to compile my main.less file to $CATALINA_EC_TMP/main.css
so the resulting file would be in that case /foo/bar/main.css or wherever the $CATALINA_EC_TMP value is.
I hope that there's a solution to this, anyway if it doesn't exist I think I'll use fswatcher to copy my generated css files into my destinations whenever I compile.
Let's say I separate a less files into many less files to be easy to organize.
Here is my repository:
/reset.less
/variables.less
/mixins.less
/main.less
/styles.less
The styles.less is just importing the other files:
#import "reset.less";
#import "mixins.less";
#import "variables.less";
#import "main.less";
However, when I add some codes into main.less and use the #line-color which is defined in the variables.less. It shows Name Error: variable #line-color is undefined and I cannot compile it- I use PHPStorm with less plugin.
Could you pleas suggest me?
You have to import your variables.less to all files which use your variables.
Edit:
You have to compile only your style.less. You cannot compile the main.less because it doesn't know the variables.less but you don't want a main.CSS anyway, do you?
You should get the correct style.css which is (I guess) the only css file you'll need.
I could solve it by doing the following in PHPstorm:
Open Preferences…
In Tools > File Watchers > Less (configure)
Check "track only root files"
Change the "Output paths to refresh" to ../css/$FileNameWithoutExtension$.css (added "../css/" in front - depending on what folder you'd like to write the css files into)
(At this point you may want to check if this already does the job to your liking. If it doesn't, carry on to the next step…)
In Other Settings > LESS Profiles > (Your profile) (configure)
Define "LESS source directory": /Users/macuser/htdocs/MySite/sites/all/themes/mytheme/less (depending on which folder contains the .less files)
Define "Include file by path": /Users/macuser/htdocs/MySite/sites/all/themes/mytheme/less/style.less (file name depending on which .less file compiles the other .less files)
Add "CSS output directory" by selecting the folder you wish to write the (minified) CSS files
Enable Compress CSS output if desired
Notice: If Compress CSS output is enabled, this means that the code will be compressed everytime you right-click a .less-file and hit "Compile to CSS". By default the output will not be compressed with every modification you make to the .less-file. If you do want to compress the CSS straight away,
Install less-plugin-clean-css using the following command in
Terminal: sudo npm install -g less-plugin-clean-css
Next, go to Tools > File Watchers > Less (configure), and change the "Arguments" to --clean-css --no-color $FileName$ (added "--clean-css" in front).
Now it will compile your CSS automatically while you're coding. You'll no longer need to compile manually.
I started using sass scss stylesheets. These generate *.css files from *.scss files. My question is, which files do you check into version control? Right now I check in both main.scss and the generated main.css. I wonder though if there is a way to just check in the *.scss file and to ensure that the *.css files get generated on deployment.
I prefer to check them in. We deploy to our staging and production environments from git and I prefer not to rely on yet another tool/compilation when deploying to production. This way, its absolutely clear what is being pushed out.
In general, you usually don't need to check generated files into source control. As long as your code generation works consistently, and you use it consistently to update your target .css files, I don't think you would need to put them in source control.
That said, the suggestion to not put generated files into source control is usually intended more for binary files (i.e. libs or executables generated from a build). The main reason for this is that binary files cannot be easily diffed/merged, so if multiple people try to checkin changes to the same binary, you may end up with merging issues that cannot be easily resolved. Since you're dealing with plain text css files, I don't think it's that big of a deal to just put them in source control too, just so you have a backup of the actual target file.
I like to borrow from the conventions used by server side developers when handling compiled front-end code like sass. I keep all of my source separate from compiled code. Here's how I set it up:
Put your source in a src directory, under main/language-name, in this case:
/path-to-my-app/src/main/sass/my-syntactically-awesome-file.scss
Then put tests in an identical test directory (you shouldn't need any tests for sass, though:
/path-to-my-app/src/test/sass/my-syntactically-awesome-test.whatever
Then put your compiled code in a publish-ready directory, like so:
/path-to-my-app/publish/css/my-syntactically-awesome-file.css
Then commit the whole shebang (!)
You can make sure you are always putting your css in the right place like so:
$ cd /path-to-my-app
$ sass --watch src/main/sass/*.scss:publish/css/
Now you're a mother effing programmer, baby!