I'm trying to find a good solution to watch a single LESS file with a bunch of imports for changes (including changes in the imported files, but only compiling the main file).
I've split my LESS into separate files as "modules" to keep it little bit more manageable and the main LESS file is just a bunch of imports. However every solution I've looked up for watching for changes instead of having to compile manually every time, either compiles every LESS file in the directory or doesn't recognize changes in the imported files.
So I'm looking for a solution that could watch changes in all LESS files, but in case of changes would only compile the main LESS file. If someone has done something like this before, it would help me a lot instead of having to make something from scratch.
Update:
I found this https://github.com/jonycheung/Dead-Simple-LESS-Watch-Compiler. By default it checks and compiles every less file in a directory. Was pretty simple to modify to watch all less files and compile only the main file when changes are detected.
LESS 1.3.1 has a new function called #import-once. Instead of #import, use #import-once.
It's not well documented, but here's the changelog and issue, discussion, more
I don't know if you're using Coffeescript, but since Less is dependent on Node you've got that installed. I created the following Cakefile which should be very easy to translate to a plain javascript file. It should also be very easy to modify for multiple files.
option '-c', '--lessFile [main Less Filename]', 'The single file to be compiled into the stylesheet, it should import any files it needs'
task 'watch-less', 'Compile Less scripts on the fly during Development', (opts) ->
less = options.less
watchers = []
compile = () ->
w.close() for w in watchers
exec "lessc #{less} #{less.replace /\.less$/, ".css"}"
watch()
watch = () ->
exec "lessc -M #{less} -", (err, stdout, stderr) ->
throw new Error err if err
watchers = (fs.watch(f, compile) for f in stdout.trim().split(' ').splice(1))
compile()
Notices and Disclaimers:
Other than less no external dependencies.
Beware the fs.watch, not cross-platform
Related
I'm trying to pack all the common libraries to be used with multiple projects without an actual entry files. Thus I need all the functions to be included in the bundle
Thus I'm trying to achieve that using #rollup/plugin-multi-entry pointing to all the files inside the directory
The problem I'm facing currently is that, some of the files extends each other, when packed, the extended function is duplicated multiple times with the name $n and so on, is it possible to make rollup not duplicate those extended functions?
Thanks
Bundling libraries inside a vendor file is now considered an anti-pattern since you will neglect the benefits of three-shaking. It will also come with worse caching since every time some lib changes the cache of the whole vendor will be invalidated and, finally, you won't benefit from http2 multiplexing that much.
If you still want to do it, in order to give them reliable names (and avoid naming conflicts) it is much easier to do it manually:
// vendor.js
import * as lib1 from 'lib1';
import * as lib2 from 'lib2';
export {lib1, lib2}
The previous module, when used as entry point, will result in exporting all exports from both libraries under its respective namespaces, and rollup will internally handle dependencies between libs correctly.
Edit: if you can bundle the libraries along with the project and not in a different process you can do it like so:
// rollup.config.js
const libs = ['lib1', 'lib2'];
{
input: 'index.js',
manualChunks: {
vendor: libs.map((lib) => require.resolve(lib))
},
// ...
}
If you modify a file under src/python, then a rebuild is necessary, unlike modifications to configs/
That makes making changes under that directory very painful, since even the clean rebuild takes several seconds.
Is there a way to avoid the rebuild?
M5_OVERRIDE_PY_SOURCE=true
If you export that environment variable for the run, and gem5 uses the Python source code directly.
This likely exists because by default, gem5 packs up Python object files inside the gem5.opt binary so allows users to run it without changing their PYTHON_PATH.
How M5_OVERRIDE_PY_SOURCE works is described here at 252dd80.
Tested on: https://gem5.googlesource.com/public/gem5/+/91295ff980c17efb3ad013b9636017b58e49c071
Preface: I'm new to cmake and only have a barely-passing knowledge of how it works, so this may not be as hard as it looks to me. :-)
For various "legacy" reasons, I'm using cmake 2.8.12, and I have a large complicated project that I did not create, but now I'm trying to figure out how to make it build faster. In the top-level CMakeLists.txt file that drives everything, there are lots of targets defined for the app build and other things, and at the end it has something like "include(StaticResources)".
StaticResources.cmake defines (and at the end, calls) a function that just iterates over a ton of dirs with static files and installs each of those dirs to the output dir, as well as installing a few explicitly enumerate files, some of which are renamed.
The problem I'm trying to eliminate is that even if a build does nothing at all, this function takes many seconds as cmake goes through and visits each dir/file to see if it needs to be copied. I'm trying to figure out how to structure this so that it doesn't even look at that stuff if nothing has changed.
Any ideas? Things I have thought of trying (but am not sure how):
- possibly make that StaticResources function depend on the main app target in some way such that it only runs when the main app has to be built (this isn't ideal, of course, because lots things can change that app without requiring resources to be deployed)
- having a StaticResources "build" target that computes a hash of the state of all of these static resources files and writes it to an output file only if something is changed, then having this static resources function install that target with custom code that actually installs the static files. It seems like this would make sure that the install is only considered if/when the resources actually change, but I'm not sure if cmake will allow me to "install(StaticResources "
The CMake doc says about the command file GLOB:
We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate.
Several discussion threads in the web second that globbing source files is evil.
However, to make the build system know that a source has been added or removed, it's sufficient to say
touch CMakeLists.txt
Right?
Then that's less effort than editing CMakeLists.txt to insert or delete a source file name. Nor is it more difficult to remember. So I don't see any good reason to advise against file GLOB.
What's wrong with this argument?
The problem is when you're not alone working on a project.
Let's say project has developer A and B.
A adds a new source file x.c. He doesn't changes CMakeLists.txt and commits after he's finished implementing x.c.
Now B does a git pull, and since there have been no modifications to the CMakeLists.txt, CMake isn't run again and B causes linker errors when compiling, because x.c has not been added to its source files list.
2020 Edit: CMake 3.12 introduces the CONFIGURE_DEPENDS argument to file(GLOB which makes globbing scan for new files: https://cmake.org/cmake/help/v3.12/command/file.html#filesystem
This is however not portable (as Visual Studio or Xcode solutions don't support the feature) so please only use that as a first approximation, else other people can have trouble building your CMake files under their IDE of choice!
It's not inherently evil - it has advantanges and disadvantages, covered relatively well in this answer here on StackOverflow. But if you use it carelessly, you could end up ignoring dependency changes and requiring clean rebuilds of large parts of your codebase.
I'm personally in favor of using it - in smaller projects, or on certain subdirectories in larger ones - to avoid having to enter every file manually into the build files. Edit: My preference has changed and I currently tend to avoid it.
On top of the reasons other people here posted, imho the worst issue with glob is that it can yield DIFFERENT file lists on different platforms. As I see it, that's a bug. In OSX glob ignores case sensitivity and in a ubuntu box it doesn't.
Globbing breaks all code inspection in things like CLion that otherwise understand limited subsets of CMakeLists.txt and do not and never will support globbing as it is unsafe.
Write script to dump the globbed list and paste it in, its very simple, and then CLion can actually find the referenced files and infer them as useful. Maybe even put such script into the tree so that the other devs can either run it without being a moron OR set git hooks to make it happen.
In no case should some random file dropped into some directory ever get automatically linked that's how trojans happen.
Also CLion without context jumping to known definitions and what not, is like hiking barefoot /// why bother.
I have two files:
black.less
/* imports */
#import "elements.less";
#import "crush.less";
#import "tree.less";
I'm using the less watch functionality by adding:
less.watch();
Sure enough I can see the traffic getting black.less. Black.less hasn't changed though so any change in any of the files being imported is not counted as a change and the style is not updated.
If I however touch black.less the style updates as it should.
Is there a way to automatically update regardless of if it's an imported file or the actual less file being added to the page i.e. so that I only have to change let's say tree.less.
/K
I use Grunt and the grunt-contrib-less plugin to watch all of my less files and compile them into CSS as they change.
Then I use live.js in the browser to watch the CSS files.
The advantage to doing it this way is that I can do the same thing with my HTML and JS files, as well as run tests, lint my JS files, etc.
Remy Sharp recently wrote a post about how newer versions of Chrome support the ability to save files that you edit in the dev tools back to the file system.
He advocates Never having to leave devtools. Just do your edits right in the browser. The advantage to this solution for you is that you could continue to use the client-side Less compiler.
(I still like my robust text editors and command-line too much to ditch them entirely, but thought this answer would likely appeal to at least a few people who arrived at this question.)
Here's another quick way.
watch -n 1 touch black.less
This may be too late for op, but I had the same question and maybe others have it too.
less-watch-compiler will watch a directory (and sub-directories) for changes and compile any less code to a destination folder. The cool bit is that you can specify the main file and only the main file will be compiled when any file in the source directory is changed.
Usage:
less-watch-compiler [options] <source_dir> <destination_dir> [main-file]