I am trying to run gcov for my unit test code. I passed "-fprofile-arcs -ftest-coverage" options through CPPFLAGS and used "-lgcov" option through LDDFLAGS.
But, gcda files are not generated when running my program. My program exits cleanly.
*pathname = /unit_test/unittest/DeveloperCmds.gcda
flags = 66
pathname = /unit_test/unittest/DeveloperCmds.gcda
flags = 66
profiling:/unit_test/unittest/DeveloperCmds.gcda:Cannot open
pathname = /unit_test/unittest/AteTests.gcda flags = 66
pathname = /unit_test/unittest/AteTests.gcda flags = 66
profiling:/unit_test/unittest/AteTests.gcda:Cannot open
pathname = /unit_test/unittest/DebugTest.gcda flags = 66*
Related
I have the following definition:
hello123 =
(pkgs.writeScriptBin "finderapp" ''
#!${pkgs.stdenv.shell}
# Call hello with a traditional greeting
ls ${pkgs.ffmpeg-full}/bin/ffmpeg
ffmpeg --help
echo hello
''
);
And the service:
systemd.services = {
abcxyz = {
enable = true;
description = "abcxyz";
serviceConfig = {
WorkingDirectory = "%h/temp/";
Type = "simple";
ExecStart = "${hello123}/bin/finderapp";
Restart = "always";
RestartSec = 60;
};
wantedBy = [ "default.target" ];
};
};
However, this seems to fail being able to execute ffmpeg:
Jul 10 19:47:54 XenonKiloCranberry systemd[1]: Started abcxyz.
Jul 10 19:47:54 XenonKiloCranberry finderapp[10042]: /nix/store/9yx9s5yjc6ywafadplblzdfaxqimz95w-ffmpeg-full-4.2.3/bin/ffmpeg
Jul 10 19:47:54 XenonKiloCranberry finderapp[10042]: /nix/store/bxfwljbpvl21wsba00z5dm9dmshsk3bx-finderapp/bin/finderapp: line 5: ffmpeg: command not found
Jul 10 19:47:54 XenonKiloCranberry finderapp[10042]: hello
Why is this failing? I assume it's correctly getting ffmpeg as a runtime dependency (verified with nix-store -q --references ...) as stated in another question here: https://stackoverflow.com/a/68330101/1663462
If I add a echo $PATH to the script, it outputs the following:
Jul 10 19:53:44 XenonKiloCranberry finderapp[12011]: /nix/store/x0jla3hpxrwz76hy9yckg1iyc9hns81k-coreutils-8.31/bin:/nix/store/97vambzyvpvrd9wgrrw7i7svi0s8vny5-findutils-4.7.0/bin:/nix/store/srmjkp5pq8c055j0lak2hn0ls0fis8yl-gnugrep-3.4/bin:/nix/store/p34p7ysy84579lndk7rbrz6zsfr03y71-gnused-4.8/bin:/nix/store/vfzp1mavwiz5w3v10hs69962k0gwl26c-systemd-243.7/bin:/nix/store/x0jla3hpxrwz76hy9yckg1iyc9hns81k-coreutils-8.31/sbin:/nix/store/97vambzyvpvrd9wgrrw7i7svi0s8vny5-findutils-4.7.0/sbin:/nix/store/srmjkp5pq8c055j0lak2hn0ls0fis8yl-gnugrep-3.4/sbin:/nix/store/p34p7ysy84579lndk7rbrz6zsfr03y71-gnused-4.8/sbin:/nix/store/vfzp1mavwiz5w3v10hs69962k0gwl26c-systemd-243.7/sbin
Or these paths basically:
/nix/store/x0jla3hpxrwz76hy9yckg1iyc9hns81k-coreutils-8.31/bin
/nix/store/97vambzyvpvrd9wgrrw7i7svi0s8vny5-findutils-4.7.0/bin
/nix/store/srmjkp5pq8c055j0lak2hn0ls0fis8yl-gnugrep-3.4/bin
/nix/store/p34p7ysy84579lndk7rbrz6zsfr03y71-gnused-4.8/bin
/nix/store/vfzp1mavwiz5w3v10hs69962k0gwl26c-systemd-243.7/bin
/nix/store/x0jla3hpxrwz76hy9yckg1iyc9hns81k-coreutils-8.31/sbin
/nix/store/97vambzyvpvrd9wgrrw7i7svi0s8vny5-findutils-4.7.0/sbin
/nix/store/srmjkp5pq8c055j0lak2hn0ls0fis8yl-gnugrep-3.4/sbin
/nix/store/p34p7ysy84579lndk7rbrz6zsfr03y71-gnused-4.8/sbin
/nix/store/vfzp1mavwiz5w3v10hs69962k0gwl26c-systemd-243.7/sbin
Which shows that ffmpeg is not in there.
I don't think this is the most elegant solution as the dependencies have to be known in the service definition instead of the package/derivation, but it's a solution none the less.
We can add additional paths with path = [ pkgs.ffmpeg-full ];:
abcxyz = {
enable = true;
description = "abcxyz";
path = [ pkgs.ffmpeg-full ];
serviceConfig = {
WorkingDirectory = "%h/temp/";
Type = "simple";
ExecStart = "${hello123}/bin/finderapp";
Restart = "always";
RestartSec = 60;
};
wantedBy = [ "default.target" ];
};
In addition to the previous answers
not using PATH
adding to PATH via systemd config
you can add it to the PATH inside the wrapper script, making the script more self-sufficient and making the extended PATH available to subprocesses, if ffmpeg or any other command needs it (probably not in this case).
The ls command has no effect on subsequent commands, like it shouldn't.
What you want is to add it to PATH:
hello123 =
(pkgs.writeScriptBin "finderapp" ''
#!${pkgs.stdenv.shell}
# Call hello with a traditional greeting
PATH="${pkgs.ffmpeg-full}/bin${PATH:+:${PATH}}"
ffmpeg --help
echo hello
''
);
The part ${PATH:+:${PATH}} takes care of the : and pre-existing PATH, if there is one. The simplistic :${PATH} could effectively add . to PATH when it was empty, although that would be rare.
I'm trying to package a bundle for uploading to Google Cloud. I have an output of pkg_web from an angular build that I did, which, if I pass into this custom rule I'm generating, is a File object that is a directory of the files. The custom rule I am generating takes the app.yaml, etc, and the bundle, and uploads.
However, the bundle becomes a directory, and I need the files of that directory expanded for uploading in the root of command.
For example:
- bundle/index.html <-- bundle directory
- bundle/main.js
- app.yaml
and I need:
- index.html
- main.js
- app.yaml
My rule:
deploy(
name = "deploy",
srcs = [":bundle"] <-- pkg_web rule,
yaml = ":app.yaml"
)
Rule implementation:
def _deploy_pkg(ctx):
inputs = []
inputs.append(ctx.file.yaml)
inputs.extend(ctx.files.srcs)
script_template = """
#!/bin/bash
gcloud app deploy {yaml_path}
"""
script = ctx.actions.declare_file("%s-deploy" % ctx.label.name)
ctx.actions.write(script, script_content, is_executable = True)
runfiles = ctx.runfiles(files = inputs, transitive_files = depset(ctx.files.srcs))
return [DefaultInfo(executable = script, runfiles = runfiles)]
Thank you for your ideas!
Seems a bit excessive, but I ended using a custom shell command to accomplish this:
def _deploy_pkg(ctx):
inputs = []
out = ctx.actions.declare_directory("out")
yaml_out = ctx.actions.declare_file(ctx.file.yaml.basename)
inputs.append(out)
ctx.actions.run_shell(
outputs = [yaml_out],
inputs = [ctx.file.yaml],
arguments = [ctx.file.yaml.path, yaml_out.path],
progress_message = "Copying yaml to output directory.",
command = "cp $1 $2",
)
for f in ctx.files.srcs:
if f.is_directory:
ctx.actions.run_shell(
outputs = [out],
inputs = [f],
arguments = [f.path, out.path],
progress_message = "Copying %s to output directory.".format(f.basename),
command = "cp -a -R $1/* $2",
)
else:
out_file = ctx.actions.declare_file(f.basename)
inputs.append(out_file)
ctx.actions.run_shell(
outputs = [out_file],
inputs = [f],
arguments = [f.path, out_file.path],
progress_message = "Copying %s to output directory.".format(f.basename),
# This is what we're all about here. Just a simple 'cp' command.
# Copy the input to CWD/f.basename, where CWD is the package where
# the copy_filegroups_to_this_package rule is invoked.
# (To be clear, the files aren't copied right to where your BUILD
# file sits in source control. They are copied to the 'shadow tree'
# parallel location under `bazel info bazel-bin`)
command = "cp -a $1 $2",
)
....
``
I have a somewhat complex SCons build script that an some point does the following two steps:
# 1: builds unit tests (googletest, shell executable)
compile_tests = some_environment.Program(executable_path, test_sources)
# 2: runs unit tests (call earlier compiled program)
run_tests = other_environment.Command(
source = executable_path,
action = executable_path + ' --gtest_output=xml:' + test_results_path,
target = test_results_path
)
Depends(run_tests, compile_tests)
This is working fine if I run scons with this build script on its own.
If I, however, invoke it via environment.SConscript() from another SConstruct file one directory level up, then step 1 adjusts the path to the project's location while step 2 doesn't. See this output:
scons: Building targets ...
g++ -o Nuclex.Game.Native/obj/gcc-7-amd64-release/NuclexGameNativeTests -z defs -Bsymbolic Nuclex.Game.Native/obj/gcc-7-amd64-release/Tests/Timing/ClockTests.o -LNuclex.Game.Native/obj/gcc-7-amd64-release -LReferences/googletest/gcc-7-amd64-release -lNuclexGameNativeStatic -lgoogletest -lgoogletest_main -lpthread
obj/gcc-7-amd64-release/NuclexGameNativeTests --gtest_output=xml:bin/gcc-7-amd64-release/gtest-results.xml
sh: obj/gcc-7-amd64-release/NuclexGameNativeTests: No such file or directory
Line 2 builds the executable into Nuclex.Game.Native/obj/gcc-7-amd64-release/ while line 3 tries to call it in obj/gcc-7-amd64-release/, forgetting the project directory.
Should I use another way to invoke my unit test executable? Or can I query the SCons environment for its base path?
Update: reproduction case, place https://pastebin.com/W08yZuF9 as SConstruct in root directory, create subdirectory somelib and place https://pastebin.com/eiP63Yxh as SConstruct therein, also create main.cpp with a "Hello World" or other dummy program.
A SCons Action (the action parameter in the Command) will use the SCons variables to substitute sources and targets in correctly, taking into account VariantDirs and SConscript directories automatically. You can find more info on these source and target substitutions here: https://scons.org/doc/HTML/scons-man.html#variable_substitution
There is a section which explains using this in regards to SConscript and VariantDirs:
SConscript('src/SConscript', variant_dir='sub/dir')
$SOURCE => sub/dir/file.x
${SOURCE.srcpath} => src/file.x
${SOURCE.srcdir} => src
So in your example I think you want to replace executable_path with $SOURCE in the action string:
# 2: runs unit tests (call earlier compiled program)
run_tests = other_environment.Command(
source = executable_path,
action = '$SOURCE --gtest_output=xml:$TARGET',
target = test_results_path
)
I'm trying to compile an iOS project that contains ARM code using the command line.
Here is the command line:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/as -arch armv6 engines/scumm/smush/codec47ARM.s -o engines/scumm/smush/codec47ARM.o
...and here are the errors:
engines/scumm/smush/codec47ARM.s:29:Unknown pseudo-op: .global
engines/scumm/smush/codec47ARM.s:29:Rest of line ignored. 1st junk character valued 95 (_).
engines/scumm/smush/codec47ARM.s:43:bad instruction `STMFD r13!,{r2,r4-r11,R14}'
engines/scumm/smush/codec47ARM.s:45:bad instruction `LDR r4,[r13,#40]'
engines/scumm/smush/codec47ARM.s:48:bad instruction `SUB r4,r4,#0xF8'
engines/scumm/smush/codec47ARM.s:55:bad instruction `ADD r7,r2,#7'
engines/scumm/smush/codec47ARM.s:56:bad instruction `MOV r7,r7,LSR#3'
If I try to compile with gcc (or clang), I receive the following errors:
engines/scumm/smush/codec47ARM.s:162:2: error: invalid instruction
LDREQB r6,[r1],#1 # r6 = t = *_d_src++
^
engines/scumm/smush/codec47ARM.s:279:2: error: invalid instruction
LDREQB r6,[r1],#1 # r6 = t = *_d_src++
^
engines/scumm/smush/codec47ARM.s:330:2: error: invalid instruction
LDRLTB r6,[r4,r6] # r6 = t = _paramPtr[code]
^
What am I doing wrong? I believe that ARMv6 should support MOV, ADD, etc.
When using the default qmake compiler (via the SOURCES variable), I can use precompiled headers like so:
CONFIG += precompile_header
PRECOMPILED_HEADER = stable.h
SOURCES = main.c
However, I'd like to use a custom compiler (via QMAKE_EXTRA_COMPILERS). I tried this:
CONFIG += precompile_header
PRECOMPILED_HEADER = stable.h
MY_SOURCES = main.c
my.input = MY_SOURCES
my.output = ${QMAKE_FILE_IN_BASE}.o
my.commands = clang $$QMAKE_CFLAGS_USE_PRECOMPILE -c ${QMAKE_FILE_IN} -o ${QMAKE_FILE_OUT}
QMAKE_EXTRA_COMPILERS += my
...and the precompiled headers are built, but my custom compiler fails because QMAKE_CFLAGS_USE_PRECOMPILE doesn't contain the path to the precompiled header. (It is defined as -Xclang -include-pch -Xclang ${QMAKE_PCH_OUTPUT}, and apparently ${QMAKE_PCH_OUTPUT} is empty.)
How can I get the name of the generated precompiled header, so I can pass it as a parameter to my custom compiler?
Looking at the qmake source code, precompiled header handling seems to be hardcoded in UnixMakefileGenerator::init() to only work for the built-in C, CXX, OBJC, and OBJCXX compilers.
QMAKE_PCH_OUTPUT, for GCC and Clang-style precompiled headers, is constructed by combining PRECOMPILED_DIR, TARGET, one of c/c++/objective-c/objective-c++, and QMAKE_PCH_OUTPUT_EXT. So, in the question's second example, the following command line should work:
my.commands = clang -Xclang -include-pch -Xclang $$TARGET/c$$QMAKE_PCH_OUTPUT_EXT -c ${QMAKE_FILE_IN} -o ${QMAKE_FILE_OUT}