First of all I have to note that this all worked well some time ago. I have returned to project after some time. Meanwhile I have updated PhpStorm and migrated to Win10. Everything else stayed untouched.
I have problem with triggering scss parial compilation. When I make changes in root file "global.scss" everything works ok - partials are also compiled. However when I make changes in partials PhpStorm not triggers compilation of root file.
PhpStorm version: 2017.2.3
File structure:
Watcher config:
Scope config:
global.scss
I have tried a lot - nothing works. It seems that partials - prefixed with underscore are just ignored by file watcher.
EDIT:
I found something - it seems that wildcard in scope pattern ignores underscored files. However partials are marked as included in files tree. I temporarly changed scope to project files and it works well - unfortunetally I can not leave this setting.
EDIT2:
I don't know is it bug or feature but PhpStorm handles nested Source roots in strange way. Check this file structure:
Without source root for scss directory, compilation is triggered even with scope pattern. However compiled css is placed in wrong directory - so it is not usable.
Based on your info and investigation: you are using nested "Source" folder (on scss) and $SourcepathEntry$ & related macro... which does not seem to work as you expected in your IDE version.
Get rid of it -- your setup does not need it at all. Your folder structure is pretty standard so it can be resolved using more "standard" ways.
Disable this File Watcher for now (you may delete it later) and make new one.
There try $FileDirPathFromParent()$ parametrized macro (it accepts parameters). For example for $FileDirPathFromParent(src)$ it returns foo/bar for some/path/src/foo/bar/baz.scss file path. This macro should do the job when making the needed path.
Related
short background info:
For some rather convoluted reasons I am trying to trick my projects build system. We are working with Code Composer Studio on Windows from Texas Instruments and the gmake implementation that was included. We use the standard Debug build option pretty much unmodified as far as I am aware of (my understanding of make and our implementation of it is unfortunately limited). When developing in Code Composer the build works as one would expect, only the files that have been changed and their dependencies are changed. Sometimes I need to regenerate all code from a code generator that we use however, triggering a complete rebuild.
Trying to trick this complete rebuild I wrote a python script that moves all the original files out from the project, waits for the code generator, then compares the files and replaces the new identical files with the old ones. Thus the creation timestamp and the last modified timestamp should be preserved. This also seems to work when examining these properties. However a complete rebuild of the problem is always triggered.
Core of the Problem:
Having already built the project in Code Composer and building again it concludes that nothing has changed and that there is nothing to do, as one would expect.
I move a file out of the folder and back in again, preserving both the creation time stamp and last modified time stamp as far as I can see (in windows explorer -> properties).
When now rebuilding the project it will rebuild the said file and its dependencies, despite it being identical to before and having the same timestamps.
What is gmake looking at? Does it detect that the folder has been changed. Is it looking at some other hidden timestamp? Is it a Windows problem? Shouldn't it be possible to do this, inserting a file with an old timestamp?
What am I missing? Anyone have a clue?
Having examined this I concluded that the problem does not lie with gmake or the makefile but with Code Composer Studio's/Eclipse makefile generation.
We use the built in makefile generation in Code Composer Studio (which is an Eclipse derivative). It seems to keep track of if files have been removed/moved out from the projects workspace. If it has it removes the dependecies of that files during the makefile generation, triggering a rebuild.
Examples:
Case 1, works as I expect:
Rebuilding an unchanged project in Code Composer Studio. Nothing is recompiled since nothing is changed.
Case 2, works as I expect:
Changing something in a single then rebuilding results in recompilation of only that single file. As I/once expects.
Case 3, does not work as I expect:
Having an unchanged project and the moving one source code file (xyz.cpp) out of the project, not changing it in any way and then mvoing it back results in a recompilation of xyz.obj.
Code Composer/Eclipse seem to keep track on the filestructure. Despite the file being put back into the project exactly the way it was, Code Composer/Eclipse deletes xyz.obj during the makefile generation, triggering a rebuild.
On the other hand; closing Code Composer, moving the file back and forth, Reopening Code Composer and regenerating makefile/rebuilding works as one expects. Nothing is rebuilt and no .obj files are removed.
Since this didn't have anything to do with gmake and makefile I guess this question was invalid/unrelevant to begin with. I will collect my thoughts and reformulate a new question formulated strictly as a Code Composer/Eclipse errand.
If anyone has found themselves in the same situation or have relevant information on their hands please share however!
I've generated a couple of helper scss files within my scss project folder indicated by a '_' prefix. On file change however, prepros will compile them into a css file.
As I understand how this should work is _ should indicate to the pre-processor to ignore the file until explicitly included into a standard .scss file. And this isn't the case. Would this be a bug in prepros or is there a configuration setting somewhere that I would need to adjust?
I know this is an older post, but what's happening is if the partials are imported into a main SCSS file, the compiler will ignore the partials as individual files and include them in the main CSS output. If they are not imported, they will compile unless you filter them in the software.
I used Prepros a lot,
I have two Solution of this.
Solution 1: It may be a bug a in software, So updating may solve your problem.
Solution 2: You may have not configured settings, So updating configuration settings.
To updating configuration settings do the following steps:
1- Click on settings
2- Now In File Watcher panel, go to Path Filters and add _*.scss in it. Now what this will do is that it will ignore all .scss extension files starting with _ containg any name.
:)
I'm using Laravel locally with XAMPP, with some code written by someone else. After installing everything I get the following directory tree:
xampp
...
htdocs
myproj
.git
app
assets
classes
commands
config
controllers
database
lang
models
start
storage
tests
views
bootstrap
provider
public
sphinx
vendor
wpplugin
...
...
I know the code uses Zurb Foundation (among other tools), with SCSS files.
In XAMPP Control Panel, in the Apache httpd.conf, I define DocumentRoot as C:/xampp/htdocs/myproj/public and this works fine.
The files xxxxxx.blade.php under views/layouts contain blade lines that look like:
{{ stylesheet_link_tag('yyyyyy') }}
Googling this, I think (not sure) it's using something called CodeSleeve to resolve yyyyyy, which, as I understand, look for yyyyyy.css files under app/assets/stylesheets. In this directory I can see both yyyyyy.css files and _yyyyyy.scss files, and I can see the former is presumably calling the latter with a require command in an alleged comment.
As long as I update controllers and/or views, I can see the changes reflected immediately under localhost in the browser. However, any attempt to modify a _yyyyyy.scss (even as much as adding a space) - results in an error in browsing, losing all the styling etc.
My question is: What is the mechanism that presumably converts the SCSS files into CSS in real-time, and how can I do testing locally with modifying the SCSS files?
It's Notepad adding the UTF-8 BOM in the beginning of the file!!
When editing with Notepad++ and saving the new file with no BOM, styling comes back again.
(Thanks to Andy who helped solving this)
I have Compile Views turned on and have just changed a big portion of my project so that a few of the views are not relevant at the moment.
I right clicked on them and chose Exclude from project.
However, these files are still be checked at compile time and come up in errors (as their ViewModel/model no longer exists).
The model/ViewModel themselves are excluded from the project and are not checked, but, these files will one day be included and I do not want to delete them.
So far, the only solution I have found is to highlight the entire content of the views and comment them out.
Whilst my solution does work, is this a bug or am I doing something wrong... or even, is there a better work around?
If the files are excluded from the project then they shouldn't be compiled.
What you might have is that the object files are still the output directory and it's these that are generating the errors.
You could either clean the project before excluding the files or simply delete the bin and obj directories to remove all the old output.
Sorry for what seems like a silly question: But I've never, ever worked with boost, until tonight, and I'm finding that getting it configured seems to be harder to use than it should be.
I wanted experiment with it tonight. So I downloaded the zip file, and unzipped it to a directory here:
F:/boost_1_44_0
Then I created an empty c++ project in visual studio 2010 (not using pch either). So all I wanted to do was to include a header file. But not even a silly thing like that seems to work. Now I've been using visual studio for years, though at work we are still stuck on vs 2008 (That is another story). So usually what you do is set an include directory, and then you can include files in at will right?
So I set the global include directory to include the boost root. i.e. Property Manager -> My configuration (debug|win32) -> Microsoft.Cpp.Win32.user -> Common Properties -> C++ Directories -> Include Directories. There I added my path to f:/boost_1_44_0.
I also went to the project properties and set the C++ include directory for the project to point to the boost root like in vs 2008.
I then added a silly include declaration like so:
#include <boost/lambda/lambda.hpp>
But, amazingly it fails to compile!!! with the following error:
Error 1 error C1083: Cannot open include file: 'boost/type_traits/transform_traits.hpp': No such file or directory f:\boost_1_44_0\boost\lambda\core.hpp 25 1 test_boost
Which when I double click it, it opens up in f:\boost_1_44_0\boost\lambda\core.hpp, and takes me to this line:
#include "boost/type_traits/transform_traits.hpp"
So I have no idea what's happening. Is visual studio just not delivering up my global include paths that I set? It seems also that the include directive in core.hpp should be using angle brackets and not quotes.
If I'm doing something wrong what?
EDIT:
!! SOLVED !!
Before I didn't have all the files unzipped. I don't know what happened. So I re-downloaded the zip file, and unzipped it again. This time the zip file took much longer to unzip, and it extracted much more files: Including the missing files.
Problem solved, my hello world app compiles just fine now.
The behaviour of compilers in locating header files is implementation defined for both the <> and "" variants.
However, based on this page for VC2010, it appears the quoted form searches a superset of the angle bracket form so I'm not sure that's the problem.
I suppose it would be a silly question to ask if the following file actually existed?
f:\boost_1_44_0\boost\type_traits\transform_traits.hpp
So, a couple of investigative jobs:
Make sure that f:\boost_1_44_0\boost\type_traits\transform_traits.hpp exists.
Try changing your top-level include to use quotes.
Try changing the include in f:\boost_1_44_0\boost\lambda\core.hpp to use angle brackets.
Make sure you try all four possibilities for those last two.
Is f: a network-mounted drive? What happens if you put it all on c:?
That last one is just in case Windows is doing some shenanigans under the covers :-)
While it's a bit overkill for this, learning to use SysInternals' Process Monitor will pay off over time. It will show you what files are actually opened, and which attempts failed. Look where Visual Studio tries to read transform_traits.hpp from, and you'll probably have the answer.