Group Item: cannot install file to same location - qbs

In my project, I have several plugins depending on a single module, containing a Group item similar to:
Group {
name: "group"
qbs.install: true
qbs.installDir: "../"
files: <filename>
}
But compilation fails with "error: Cannot install files 'filename' and 'filename' to the same location 'location'". Basically, qbs cannot copy same file to same location twice (seems illogical to me)
How can this bug be resolved or is there any elegant workaround?

This is a job for the qbs.installSourceBase property. Basically, you set this to the base directory containing the files in your Group, and Qbs will install the listed files into qbs.installDir hierarchically based on their paths relative to the aforementioned base directory.
For example, given the following Group:
// defined in /source/myproject/myproject.qbs
Group {
qbs.install: true
qbs.installDir: "share/stuff"
qbs.installSourceBase: "." // relative to /source/myproject
files: [
"fileA.txt",
"fileB.txt",
"subdir/fileB.txt",
]
}
and the following command line invocation:
$ qbs [...] --install-root /sample/some-root
the following filesystem hierarchy will result:
/sample/some-root/share/stuff/fileA.txt
/sample/some-root/share/stuff/fileB.txt
/sample/some-root/share/stuff/subdir/fileB.txt
See the Qbs Installation Properties documentation for more info.

There is a workaround, which may require some restructuring of a project:
instead of:
Module {
name: "somemodule"
// module properties set to dependant products
Group {
// files to install
qbs.install: true
}
}
we can use:
Product {
name: "somemodule"
Group {
// files to install
qbs.install: true
}
Export {
// module properties set to dependant products
}
}
This way, files are only installed once when steps for mymodule are run, thus eliminating the conflict. Module properties, exported via Export Item, work just as ones exported via Module.
Limitations:
Product has to be added to references of the Project Item
Modules cannot depend on Product Items, which may require to restructure all dependant modules into Project/Export pairs too

Related

AWS CDK asset path is incorrect

On September 6, I ran a build using CodePipeline. It generates a CloudFormation template for a project's stack using CDK. The stack has assets (a Lambda Layer), and the assets are correctly placed in the cdk.out folder. This can be seen in the CloudFormation template:
"Metadata": {
"aws:cdk:path": "MyStack/MyLayer/Resource",
"aws:asset:path": "asset.ccb8fd8b4259a8f517879d7aaa083679461d02b9d60bfd12725857d23567b70f",
"aws:asset:property": "Content"
}
Starting yesterday, builds were failing with "Uploaded file must be a non-empty zip". When I investigated further, I noticed that the template was no longer correct. It has the asset path set to the source code of the Lambda instead:
"Metadata": {
"aws:cdk:path": "MyStack/MyLayer/Resource",
"aws:asset:path": "/codebuild/output/src216693626/src/src/lambdas/layers",
"aws:asset:property": "Content"
}
When I build, I've added additional commands to the buildspec file which shows that the assets.abcdef folder has the layer and its dependencies, while the src folder does not. Yet the template is now different.
No code was changed in this time period, and I've tried both CDK version 1.105.0 and 1.119.0.
This code declares the Layer:
new lambdapython.PythonLayerVersion(this.stack, 'MyLayer', {
entry: path.join(__dirname, '../../src/lambdas/layers'),
description: 'Common utilities for the Lambdas',
compatibleRuntimes: [lambda.Runtime.PYTHON_3_8],
layerVersionName: `${Aws.STACK_NAME}Utils`,
});
Is there a known way for me to force the stack to use the assets in the cdk.out folder? Has something changed in the last couple of days with respect to how CDK generates the template's asset path?
It turns out that I had added a cdk ls to print out additional debugging information while troubleshooting another problem. That command re-synthesized the stack, but with the incorrect asset path.
build: {
commands: [
'cd ' + config.cdkDir,
'cdk synth',
'cdk ls --long'
]
}
The solution was to delete the cdk ls --long from the buildspec definition.

Requiring config.js file in VSCode extension with absolute path (e.g. "C:\...") does not work

I am developing the Argdown VSCode extension. The Argdown parser can be configured using either argdown.config.json files or argdown.config.js files exporting a config object. Using Javascript files is the easiest way to allow users to add custom plugins to the Argdown parser.
If the user tells the parser to use a Javascript file, the file is loaded using import-fresh, (which uses node's require, but deletes the cached version.
Using the Argdown commandline tool (#argdown/cli) this works fine, but in the VSCode extension the module of the config file can not be found. The extension is using absolute file paths to require the config module (e.g. "C:\Users\my-username\projects\my-argdown-project\argdown.config.js"). These paths work with import-fresh outside of the VScode extension.
Is there a security restriction for VSCode extensions that does not allow to require modules with absolute file paths? Or is there some other reason why this does not work?
This was not related to VSCode. The problem was caused by bundling up import-fresh with webpack. I thought that webpack would ignore dynamic imports, but it did not.
I was lucky: Since last month, webpack supports "magic comments" for require (not only for import). So I can use:
require(/* webpackIgnore: true */ file);
You have to activate magic comments support in your webpack config:
module.exports = {
parser: {
javascript: {
commonjsMagicComments: true,
},
},
}
Now the next question is how to add the magic comments to the import-fresh package. For that I used the string-replace-loader:
module.exports = {
module: {
rules: {
{
enforce: "pre",
test: /import-fresh[\/\\]index\.js/,
loader: "string-replace-loader",
options: {
search:
"return parent === undefined ? require(filePath) : parent.require(filePath);",
replace:
"return parent === undefined ? require(/* webpackIgnore: true */ filePath) : parent.require(/* webpackIgnore: true */ filePath);",
},
},
}
}
}
After that, I could load the argdown.config.js files again, even after bundling everything with webpack.

Qbs: install files preserving hierarchy

I have directory with files in subdirectories to be deployed with my application (qml plugins). The trouble is: if I try to install dirs:
Group {
name: "somegroup"
files: ["mysrc/dir"]
qbs.install: true
qbs.installDir: "mybuild"
}
I get a "Not recursively copying directory 'mysrc/dir' into target directory 'mybuild'. Install the individual file artifacts instead." error.
If I try to install files:
Group {
name: "somegroup"
files: ["mysrc/dir/**/*"]
qbs.install: true
qbs.installDir: "mybuild"
}
Then all of those files go into same directory ignoring hierarchy (and cannot be installed, because some of them share name).
Solution with multiple groups is too verbose either.
Is there a way to install directory with files, recursively, preserving hierarchy?
See the qbs.installSourceBase property; that's exactly what it is for.
example usage:
Group {
name: "qt_qml_plugins"
prefix: Qt.core.pluginPath + "/../qml/"
files: [
"QtQml/**",
"QtQuick/**",
"QtQuick.2/**",
"QtPositioning/**",
"QtLocation/**"
]
excludeFiles: ["**/*d.dll"]
qbs.install: true
qbs.installDir: "../../qml"
qbs.installSourceBase: prefix
}

DSC Package resource have identical key properties

I'm trying to first uninstall a package, then install the latest version of that same package. Simple you would think, but when I include the following code in my DSC configuration:
### remove old product setup
Package removeOldProduct {
Ensure = 'Absent'
Name = 'My Product Name'
Path = ""
ProductId = ""
}
### now install the latest product setup
Package productSetup {
Ensure = 'Present'
Name = 'My Product Name'
Path = "$productShare\Repository\product.msi"
ProductId = ""
Arguments = "ACCEPT_EULA=1 /q"
DependsOn = '[Package]MsSql'
}
While creating the .mof file, I receive the following error:
Test-ConflictingResources : A conflict was detected between resources '[Package]productSetup and '[Package]removeOldProduct in node 'myNodeServer'. Resources have identical key properties but there are
differences in the following non-key properties: 'Path;Ensure;Arguments'.
I don't want to use a Script resource to process my uninstall. What am I doing wrong here?
Your configuration is supposed to be idempotent, generally, so this doesn't make a lot of sense. You would be uninstalling and reinstalling the package every time the configuration is applied (every 30 minutes or whatever it's set to).
An MSI installer should support upgrading automatically, which means you would just ensure the installation of the (newer) MSI.

Protobufs import from another directory

While trying to compile a proto file named UserOptions.proto which has an import named Account.proto using the below command
protoc --proto_path=/home/project_new1/account --java_out=/home/project_new1/source /home/project_new1/settings/Useroptions.proto
I get the following error :
/home/project_new1/settings/UserOpti‌​ons.proto: File does not reside within any path specified using --proto_path (or -I). You must specify a --proto_path which encompasses this file.
PS: UserOptions.proto present in the directory /home/project_new1/settings
imports Account.proto present in the directory
/home/project_new1/account
Proto descriptor files:
UserOptions.proto
package settings;
import "Account.proto";
option java_outer_classname = "UserOptionsVOProto";
Account.proto
package account;
option java_outer_classname = "AccountVOProto";
message Object
{
optional string userId = 1;
optional string service = 2;
}
As the error message states, the file you pass on the command line needs to be in one of the --proto_paths. In your case, you have only specified one --proto_path of:
/home/project_new1/
But the file you're passing is:
/home/project_new1/settings/UserOpti‌ons.proto
Notice that the file is not in the account subdirectory; it's in settings instead.
You have two options:
(Not recommended) Pass a second --proto_path argument to add .../settings to the path.
(Recommended) Use the root of your source tree as the proto path. E.g.:
protoc --proto_path=/home/project_new1/ --java_out=/home/project_new1 /home/project_new1/settings/UserOpti‌ons.proto
In this case, to import Account.proto, you'll need to write:
import "acco‌​unt/Account.proto";
For those of us who want this really spelled out, here is an example where I have installed the protoc beta for gRPC using NuGet Packages Google.Protobuf, Grpc.Core and Grpc.Tools. My solution packages are one level above my Grpc directory (i.e. at BruTrader\packages). My .proto files are at BruTrader\Grpc\protos.
1. My .proto file:
syntax = "proto3";
import "timestamp.proto";
import "enums.proto";
package BruTrader.Grpc;
message DividendMessage {
double amount = 1;
google.protobuf.Timestamp dateUnix = 2;
}
2. my GenerateProto.bat file:
..\packages\Google.Protobuf.3.0.0-beta2\tools\protoc.exe -I..\Grpc\protos -I..\packages\Google.Protobuf.3.0.0-beta2\tools\google\protobuf --csharp_out=..\Grpc\Generated --grpc_out=..\Grpc\Generated --plugin=protoc-gen-grpc=..\packages\Grpc.Tools.0.13.0\tools\grpc_csharp_plugin.exe %1
3. my BuildProtos.bat
call GenerateProto ..\Grpc\protos\masterinstrument.proto
call GenerateProto .\protos\instrument.proto
etc.
4. BuildProtos.bat is executed as a Pre-build event on my Grpc project like this:
CD $(ProjectDir)
CALL "$(ProjectDir)BuildProtos.bat"
For my environment, Windows 10 Pro operating system and C++ programming languaje, I used the protoc-3.12.2-win64.zip that you can downloat it from here. You should open a Windows PowerShell inside the protoc-3.12.2-win64\bin path and then you must execute one of the next commands:
.\protoc.exe -I=C:\Users\UserName\Desktop\SRC --cpp_out=C:\Users\UserName\Desktop\DST C:\Users\UserName\Desktop\SRC\addressbook.proto
Or
.\protoc.exe --proto_path=C:\Users\UserName\Desktop\SRC --cpp_out=C:\Users\UserName\Desktop\DST C:\Users\UserName\Desktop\SRC\addressbook.proto
Note:
1- My source folder is in: C:\Users\UserName\Desktop\SRC
2- My destination folder is in: C:\Users\UserName\Desktop\DST
3- My .proto file is in: C:\Users\UserName\Desktop\SRC\addressbook.proto