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.
Related
I am currently working on changing our codebase to use Nuget. As part of the process the copying of ressources to the output directory should be moved from postbuild events in the projects to the files tag in the .nuspec file.
For the particular project the ressource was called Resources.resx and is renamed to something more specific during the copy (yes I know great programming - not mine and not my place to change it).
Is it possible to change the filename using the file node in nuspec or do I need to keep a postbuild in this case?
My attemp of renaming it with the target property fails:
< file src="foo/bar.resx" target="foo/foobar.resx"/>
creates the following output:
"foo/foobar.resx/bar.rex"
I found a familiar problem on github but it was rejected due to being posted on a dead branch and not trying to rename a file but change its type.
https://github.com/NuGet/Home/issues/2019
Thanks for the help
This functionality is not built into NuGet. The only conceivable way to do this would be to implement a powershell script (install.ps1) that would handle the rename of both the file and the csproj.
Late to the party, but this looks like it could work:
From: https://learn.microsoft.com/en-us/nuget/reference/nuspec
Renaming a content file in the package
Source file:
ie\css\style.css
.nuspec entry:
<file src="ie\css\style.css" target="Content\css\ie.css" />
Packaged result:
content\css\ie.css
Edit:
I found this post (https://stackoverflow.com/a/45601252/182888) where it says:
Note: The File extension in src and target must match or the specified target will be treated like a directory.
So keep that in mind or it might trip you up.
I'm struggling with the includePath setting on a bigger project source.
Let's say I have a folder structure like:
/BaseComponent/public
/BaseComponent/include
/BaseComponent/source
/SubComponent1/public
/SubComponent1/include
/SubComponent1/source
/SubComponent1/SubSubComponent/public
/SubComponent1/SubSubComponent/include
/SubComponent1/SubSubComponent/source
/SubComponent2/public
/SubComponent2/include
/SubComponent2/source
I tried to do a configuration like this:
"includePath": [
...
"${workspaceRoot}",
"${workspaceRoot}/*/include",
"${workspaceRoot}/*/public"
],
But this didn't appear to work out. Is there a way to have just all header inside the workspaceRoot used? Something like "include all subfolder"?
OR another way to define a path which is project in dependend?
I believe this is what you are looking for:
"${workspaceFolder}/**"
Assuming all the dirs are inside your working space folder.
That is not yet possible/supported, as mentioned in Microsoft/vscode-cpptools issue 849.
Example of a context illustrating that issue:
The includePath doesn't seem to work with NuGet packages since the directory name includes the version.
For example, if we use package rapidjson 1.0.2 and later upgrade, we'd have to update references to "packages/rapidjson.1.0.2/build/native/include" in this file - in additional to any packages.config files.
It would be nice if we could use wildcards in directory specifiers or some other means of not having to maintain the same information in two different places.
So the alternative is to version a script able to generate the configuration file by updating the IncludePath section with all include folders found.
Note: issue 849 is actually a duplicate of issue 723, which states (Bob Brown, from Microsoft):
A middle wildcard is not currently supported.
I started a branch that would support this a while ago, but I forget what state it was in and now the branch is out of date.
If anyone wants to get it back in sync with master and finish it, we can consider taking it.
I'll reopen this issue since the original request was not actually addressed.
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?
I'm using CMake 2.8.2 version. The project is using lots of external files and custom libraries (unavailable through find_package) and there is a long cascade of elements like the one below:
find_path(XXX_INCLUDE_DIR XXX.h /XXX/include)
if (XXX_INCLUDE_DIR)
message(STATUS "Includes (XXX) found in ${XXX_INCLUDE_DIR}")
else()
message(FATAL_ERROR "Includes (XXX) not found")
endif()
There is over 20 things like this in the script - it doesn't look good. According to the documentation, unfortunately, neither find_path nor find_library have a REQUIRED option which would do the job here (just like it does with find_package - if not found, the script stops). Do you have an idea how can I shorten the CMake script code? Something like
find_path(XXX_INCLUDE_DIR XXX.h /XXX/include REQUIED)
or something similar would be great.
Put them in your custom FindXXX.cmake modules. Read the docs and look at FindPNG.cmake for an example. Put them into <project>/cmake/FindXXX.cmake (or similar), and then add the directory containing these files to the CMAKE_MODULE_PATH and use find_package(), e.g.
list(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/cmake")
find_package(XXX REQUIRED)
You probably want to use either a macro or a function.
For instance I set the source code path as c:\code\testapp\src. Is this then available as a var I can use - for instance so I can spit out a tag file in a location relative to this, not relative to the working dir of doxygen? I think I'm looking for something like how Ant defines vars for just about everything and these can be re-used; does Doxygen have special vars for any of the config values?
I'm thinking like $PROJECT-NAME or %VERSION% or whatever...
You can use environment variables in the configuration file; the syntax is the same as in a makefile, i.e. $(VAR_NAME)
I am not sure, but I have seen people use variables as part of their build process. For example the lemon graph library uses cmake, sets a variable for the absolute file path in cmake and the doxygen config file includes variables such as #abs_top_srcdir#. Through the build process these variables are replaced with the relevant text.