I start Karma with, basically, node wrapper.js. That wrapper sets up the configuration including calling karma-coverage, starting Karma with require('karma').runner.run. karma-coverage calls out to Istanbul. (phew!)
I'd like to configure Istanbul with an .istanbul.yml file, mostly because I want to change the 'reporting watermarks'. Here's what my file looks like.
reporting:
watermarks:
statements: [90, 97]
lines: [90, 97]
functions: [90, 97]
branches: [90, 97]
That looks correct, from what I've seen. But.. it doesn't work. I assume the problem is that istanbul doesn't know the current working directory or somehow this needs to be specified through karma-coverage.
If it helps, my Karma config.basePath is simply ''.
I've attempted to find discussion of this specific problem. Sadly, this question is the closest to my problem, but it's a FAQ entry about "how to name the file". Here's a question/answer discussing this in Grunt, but I wasn't able to extract anything useful.
I also trawled through the karma-runner issues on github, both open and closed. Looking at the source to karma-runner and combining it with this issue from Istanbul, I assume it's not possible because of this line. Am I correct?
Use the following process:
Go to the istanbul directory within the karma-coverage module:
cd node_modules/karma-coverage/node_modules/istanbul
Go to the lib directory:
cd lib
Add the .istanbul.yml file there
The config.js script in the lib directory finds the path to the .istanbul.yml file via the following line:
path.resolve('.istanbul.yml')
That's it.
The path.resolve method works as follows:
If after using all from paths still no absolute path is found, the current working directory is used as well. The resulting path is normalized, and trailing slashes are removed unless the path gets resolved to the root directory.
References
node.js Path Module: Resolve method
istanbul config.js: .istanbul.yml path
How do you force the absolute path for node modules?
People complaining about strange coverage reports
.istanbul.yml work with gulp-istanbul?
Related
So I'm trying to change the directory the integrated terminal runs my Python scripts in from the root workspace (the default, I guess) to the running file directory. I want to do this as I'm more used to work with paths relative to running file than to root dir. Also sometimes I use quite large directory trees and even paths to near directory files get quite long by starting them from root dir. This would also allow me to use Path Intellisense extension as it seems to base suggestions on the current file dir.
I heard about changing the lauch.json file but I'm looking for a definitive solution that avoids having to change this in all projects.
I have already tried to change settings.json cwd option to "terminal.integrated.cwd": "${fileDirname}" but it doesn´t seem to take any effect, even after reloading.
I'm not sure what other infos are relevant here, but nevertheless i'm running vscode on windows 11 version 21H2. Any other info feel free to ask.
Thank you all in advance
I am using Conan package manager on Windows to create a package. The conan command to create the package copies files to a folder within %USERPROFILE%\.conan (or C:\Users\xxxxxxx\.conan). Then from this location it builds a Visual Studio project and ultimately calls doxygen.exe to create a .chm help file in a post-build command. The doxygen command fails with:
error : failed to run html help compiler on index.hhp
Further investigation reveals the hhc.exe command executed by doxygen is failing with:
C:\Users\xxxxxxx\.conan\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation>"C:/Program Files (x86)/HTML Help Workshop/hhc.exe" html\index.hhp
HHC5010: Error: Cannot open "C:\Users\xxxxxxx\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation\html\Module.chm". Compilation stopped.
Close inspection reveals that in the error message, the ".conan" folder is missing. Sure enough, I confirmed that hhc.exe fails when the index.hpp resides in a folder that has a parent folder that starts with a ".".
Attempts to resolve this:
changing the Doxyfile setting OUTPUT_DIRECTORY to "$(TMP)/DoxygenModule" resolves the error, but creates the .chm file in another location, which I do not prefer.
navigating to the 8DOT3 name of the ".conan" folder, which is "CONAN~1", to run the hhc.exe command, succeeds, but unfortunately I have no way of getting conan to use this 8DOT3 path for creating the package. E.g. C:\Users\xxxxxxx\CONAN~1\...
I can live with the using the %TMP% folder but would prefer generating the .chm in the current folder. Anyone have any ideas?
HTML Help Workshop v1.31 is installed on my machine at C:\Program Files (x86)\HTML Help Workshop, probably from a Visual Studio installation (not sure). I attempted using a version downloaded from Microsoft website (v1.30) as well, which made no difference.
Other info: Conan version 1.18.0, Doxygen version 1.8.14, Windows 10 Version 1809
Unfortunately not a solution, but this is a known limitation in the hhc.exe, see: https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
Edit 2019-11-15:
I've just pushed a proposed patch to github (pull request 7402, https://github.com/doxygen/doxygen/pull/7402).
This proposed patch changes inside doxygen from the current directory to the short named current directory, but just for the HTML Help compilation.
Edit 2019-11-16:
Code has been integrated in the master version on github.
This is not an answer either. Actually, you found the answer and workaround[s] yourself.
Use OUTPUT_DIRECTORY to specify a directory containing no folder names beginning with periods.
The error you described is a known issue of the MS HTML Help compiler. More general, the HTML Help compiler does not like some folder and file names. Try and stick with these characters _, a..z, A..Z, 0..9. Do not use these signs in particular ., -, # .
Please note that the proprietary CHM file format is about 20 years old (Windows 95, ...). HTML Help is in maintenance mode, which means no new features and bug fixes are expected for either the runtime or the compiler. All mainstream development on HH has stopped.
There is no way to avoid this error if a directory name above begins with a period. Not even if only the necessary files are written by Doxygen and compiling of the index.hhp is done by a third-party tool like FAR HTML using your path that contains .conan. This is because all applications are using the faulty HHA.dll.
The above applies of course to the entire workflow you have described. Maybe you can interrupt it.
Doxygen can be configured not to call the HTMLHelp compiler. Just uncheck the GENERATE_HTMLHELP option (DoxyWizard: Experts > Topics > HTML). You have all files generated by Doxygen in your preferred output directory - but of course without the CHM file. This can be imported later e.g. by HelpNDoc and compiled as a CHM file in another location.
If you can interrupt the workflow and can also make changes to Doxygen's settings, then a preference setting of OUTPUT_DIRECTORY to e.g. C:/CacheMenu/CONAN~1/DOXYGE~1 also works as expected (here used as test case).
No matter what you do, your workaround and copy and paste from another directory outside is a quick solution at this stage. Please note the EDIT in #albert's answer.
I have some C++ code that I need to compile using Adacore GNAT Programming Studio.
One file (SomeHeader.h) is in a Common directory (../../Common/) relative to my GPR file.
Our convention for C++ include directives is to use
#include "Common/SomeHeader.h"
No matter what I do, I cannot get GprBuild to find "Common/SomeHeader.h"
I followed the instructions here at AdaGem 108 with modifications for C++
for Include_Switches ("c++") use ("-I ../../");
and
for Include_Path ("c++") use "../..";
None of this seems to work for me during gprbuild and frustratingly I can't seem to get at the backend command that gprbuild is using even after turning the build verbosity up.
I see some temp files in the build messages but they get deleted before I can access them.
I am using Adacore GPS 17.1 on Windows 10 i686-pc-mingw32, GNAT Pro 17.1.
Does anyone know how to get include search paths working in Adacore's Gprbuild?
If you want to use relative paths, and you are dead set on using the -I flag, be aware that the current directory at the time you compile your c++ code it is set to the obj directory configured for grp.
So if the directory you want to include is located at C:\Foo\Bar\src\include\ and your grp obj directory is at C:\Foo\Bar\env\gpr\obj then your relative path will need to use -I..\..\..\src\include
I haven't tried to use gprbuild for compiling C++ source text yet, but I suppose it works more or less like with Ada, where you add the relevant directories to the Source_Dirs attribute:
project Cookie is
for Languages use ("C++");
for Source_Dirs use (".",
"../..");
[...]
end Cookie;
When creating RPM packages: How do I tell CPack to treat a file as config file so it won't get overridden when updating the RPM?
The %config directive is used in rpm-spec for that case. Is there something like this in CPack?
As of now, files specified with an absolute path will get marked with %config, files with a relative path are marked as 'normal' files.
A quick look at what appears to be the CPack documentation doesn't show me anything that looks like it is directly relevant or helpful here.
However, if you are using a new enough version of CMake (2.8.1+ it looks like) or apply the patch yourself it looks like you can manually specify the spec file to build by using CPACK_RPM_USER_BINARY_SPECFILE.
I just setup hudson (CI), how do I tell this Dude that my NAnt.exe is not in the \bin folder?
it's keep looking for this path:
C:\myProjects\web2009\tools\nant\bin\NAnt.exe //doesn't exist
but in the reality I setup it, in here:
C:\myProjects\web2009\tools\nant\NAnt.exe // the correct path
Have you looked at the Hudson configuration page? It should be configurable there:
http://hudson:8080/configure
The Nant plugin has a wiki page which says in part:
In order to use this plugin, you need to first
configure a NAnt installation, which can be done on
the Hudson Configuration page. Simply specify a name
for the installation, and the path to the installation
directory.
The Wiki Page answer to simply specify a name and path is NOT enough.
It seems that the installation path for the NANT HOME makes an "assumption" that there is a further \bin folder where the actual EXE is located. We all know what happens when you make an assumption.
So, for example:
My nant was located in
C:\Code\Projects\Learning_Hudson\tools\nant
and I kept getting errors, even though that was the same path I used in my NANT HOME config value. But I did keep getting a "not a directory" error on my NANT HOME with the above path.
So, after searching for an answer, which I didn't find, I found this question and it helped me figure out to MOVE my nant files to a bin subdirectory.
C:\Code\Projects\Learning_Hudson\tools\nant\bin - is where I moved the nant files
and the I left the NANT_HOME configuration path as
C:\Code\Projects\Learning_Hudson\tools\nant
and that got ride of the errors, and I finally got a successful build after 12 attempts, and lots of configuration changes.
Hudson seems to expect NANT_HOME to point to a folder that contains a bin directory where nant.exe can be found.
This confused me as well at first, but I just moved my Nant\bin folder to the appropriate location to get Hudson to save the setting. (I'd imagine you can do the same thing to get your setup working.)