I have got the same issue as the guy in this post: https://intellij-support.jetbrains.com/hc/en-us/community/posts/206447829-File-watchers-issues-and-LESS
#Andriy Bazanov suggests to "hard code what file to compile". My question is, how do you do that?
This is what my settings currently looks like:
I would like it to always compile the root file upon detecting a change in the custom scope I specified. The root file it should compile is located at C:\Users\...\react-designer\less\style.less.
Currently, it seems to only recompile the file that is being changed, but I am not completely sure about this being the case.
Related
I am using CMake to link and build my C++ project, and in said project I am using the fstream library to read from a file. However, when passing the path of the file to my code, I am forced to use a long string such as "../../../../folder/folder/folder/file" to properly reference which file I want opened. I presume this is because my .exe that CMake creates is buried deep, "far" away from my source code, which is why I would have to backtrack so much.
I am wondering if there is something I could put in my CMakeLists.txt to potentially allow for the shortening of this inclusion path.
To save myself some time I have not included my file structure as of now, but if it is needed in order for a solution to be formed I certainly can edit and add it in. I do not necessarily need a case-specific solution, rather just a generalized method in which I could go about doing this.
It looks like CMake doesn't provide such functionality , CMake doesn't do much with execution of your application.
So, For solution you have following
can either create a shell script to copy the file into the desired location which can be picked by the executable and shell script can be run while make process
pass it as a commandline argument to your c++ executable.
create a macro with this location and use this macro in the source file : - CMake can help you in this
Using add_compile_definitions( ...)
Lets make obscure question simple...
We have a solution which consists of many projects and some of them have set Custom build events using 3rd party stuff for some dark magic compilation and looks similar like this:
<CustomBuild Include="..\folder\somestuff.xyz">
<FileType>Document</FileType>
<Command Condition="'$(Configuration)|$(Platform)'=='Release|x64'">C:\Tcl\bin\tclsh.exe $(APP_PATH)\modules\APP\bin\generator.tcl -o %(RelativeDir)%(Filename) %(RelativeDir)%(Filename).xyz</Command>
<Message Condition="'$(Configuration)|$(Platform)'=='Release|x64'">APPGEN %(RelativeDir)%(Filename)</Message>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">%(RelativeDir)%(Filename).cpp;%(RelativeDir)%(Filename).h;%(RelativeDir)%(Outputs)</Outputs>
</CustomBuild>
This was working properly until we switch form VS2015 to VS2019 as now during the compilation it reports that:
Project is not up-to-date: build output 'd:\projects\program\app\src\plugins\shared\' is missing. This would be more or less ok, but it forces the compiler to recompile also the dependencies of this project and this start to be really annoying as you need to rebuild several projects everytime even when no changes were done.
I found out that the problem originates from this line of Custom build:
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">%(RelativeDir)%(Filename).cpp;%(RelativeDir)%(Filename).h;%(RelativeDir)%(Outputs)</Outputs>
More precisely from this part: %(RelativeDir)%(Outputs) as the check for .cpp and .h file in the same tag do not generate any issues. So I removed this check for directory. When this chunk of code is removed the project compiles properly and do not re-compile all day long.
So why the Custom build's Output check is now working properly just with files and directories are generating this kind of issue?
And yes, the examined dir exists and it refers to the existing correct path.
The real problem is that your real project is always rebuild due to the metadata Outputs.
The special point is that you should make sure the validity and legitimacy of the value of Outputs.
The problem is under %(RelativeDir) of %(RelativeDir)%(Outputs). When you add it, the outputs has an illegal folder structure rather than a file which makes the outputs always find the missing illegal folder structure so that causes the project always rebuild.
Let me describe it in detail,
when msbuild reads outputs proeperty, when it reads till %(RelativeDir)%(Filename).cpp;%(RelativeDir)%(Filename).h;%(RelativeDir), the value of Outputs is this:
..\folder\somestuff.cpp;..\folder\somestuff.h;..\folder\
Then, it reads %(Outputs)(reads itself), which is more like copy the above value twice:
..\folder\somestuff.cpp;..\folder\somestuff.h;..\folder\..\folder\somestuff.cpp;..\folder\somestuff.h;..\folder\
You will find the last part ..\folder\ is not a file and it is a folder structure which is illegal for the outputs.
That is the reason.
And it is more like your problem that the folder structure d:\projects\program\app\src\plugins\shared\ is missing.
Suggestion
So you should not add outputs again.
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">%(RelativeDir)%(Filename).cpp;%(RelativeDir)%(Filename).h;</Outputs>
Is there a way to do so ? I searched Google but couldn't find any answer, so I guess the answer would be no. Is there anything close ? If not, would it be easy to extend red-lang to do so ?
From http://www.rebol.com/docs/setup.html
Startup Scripts
When REBOL starts it will automatically run the rebol.r and user.r files, if they exist.
The system looks for these files first in the current directory (or the directory of the script being run), then in the directory that contains the REBOL executable program.
Note that REBOL/Core runs fine without the rebol.r and user.r files. They simply provide an easy way to include additional code and data on startup, such as your network preferences.
If you compile your own Red interpreter you can add an autoloading file, maybe in console.red after system/console/init "Red Console" and before system/console/launch Best advice is to ask on the https://gitter.im/red/help site to ask for help. I guess this was already discussed.
I am trying to implement a custom IPCore for the Zedboard. In my User_Logic I am including a component (My_Module) from the VHDL module (My_Module.vhd) which I wrote as part of the ISE project. But when I come to generate the bitstream for my design in PlanAhead it asks for the My_Module.ngc as if it is treating it as a blackbox. I though the NGC was only required when using CoreGen IPCores, but it seems it also wants it for any VHDL module included as I guess this is a 'black box'.
The issue is how do I create a NGC file from the VHDL for this module, which is part of an ISE project. As I can't find any function in ISE that allows you to just generate the netlist for one VHDL module. Or can I export this module out into a separate ISE project and then synthesise it to get the .ngc?
Many thanks
Sam
Are you sure you've typed the module name in exactly the same way both in your module .vhd file, and in the file using the module as a component?
Under normal circumstances, if your project includes the module as a .vhd file, it'll just be synthesized along with the rest of your sources - I did a quick test and renamed a component in one of my own projects, and got a complaint about a possibly missing .ngc file (this was in ISE, and not in PlanAhead though).
So the answer is to generate the NGC files by making the modules you want "the top module" you can then run the synthesis to generate the individual NGC. Then proceed as normal when adding IP to a PCore. So adding these NGC files to the netlist folder and modifying the BBD file and all that!
As a note for completion to get the module working you need to set the synthesis setting "Xilinx Specefic" -> and disable "add io buffers"
Are you including My_Module.vhd as a source file in your ISE Project? If you are, check to see that the ISE project doesn't have a yellow question mark next to the My_Module component. If it does, then it needs more information about that component. You should see a little icon with the letters VHD in it in your ISE Implementation Hierarchy View.
I made some test and I was able to create and remove boost::interprocess::shared_memory_object in a C++/CLI executable without problems. In a C++/CLI dll plugin I'm only able to create the boost::interprocess::shared_memory_object but the removal fails. I verified that the file exists at the time of removal - it is present in boost::interprocess folder in a subfolder named "20110606204418.125000". The memory hasn't been mapped by any other process. Any ideas what might be the cause? At the beginning I thought it may have something to do with the project being a dll and targeting CLR but honestly I don't know.
EDIT: the removal code is called by a different thread than the creation code - is this disallowed?
During debugging I noticed that the file path that is to be removed inside boost::interprocess::shared_memory_object::remove is different from the file created by boost::interprocess::shared_memory_object constructor - the path to be removed points at the root of "boost_interprocess" folder while the actually created file is in the "boost_interprocess/20110606204418.125000" folder. So I reported a bug to boost. We will see what they do about it.