I'm looking for a way to write the standard output of my nmake call to a specified file. I tried something like "nmake target > file.log", but this won't work. Moreover I call multiple nmakes from within my MAKEFILE and may use multiple log-files to keep track of the output. I've only found the nmake option to write errors to a file but what's about the standard output.
Is there a simple way to do that (in Windows)?
#Cheeso
I've tried to built simple example and noticed that it doesn't work for me because the MAKEFILE must running in elevated mode. Consider a makefile like this:
default:
REM Test
and a batch-file like this:
cd /d "%~dp0"
nmake output.log
pause
When running the batch-file as administrator it doesn't redirect the stdout to my file and returns an error.
jom is really picky, and it's made based on nmake. Since that's the case, we're probably dealing with the same pickiness.
This works : jom -j 8 >> build.log
While this doesn't work : jom -j 8>>build.log
Add some whitespace, and you should be good to go. This was incredibly annoying for me too with Qt 5.6.1-1. I even tried using Powershell transcripts, but that ended up being a complete bust.
Related
I have a java_binary target in my workspace that I'm later passing as an executable to ctx.actions.run inside the rule. So far so good.
Now I want to debug this java_binary while Bazel is executing the rule. In order to attach a debugger I need the java_binary run in debug mode. So far, the only thing I came up with is setting jvm_flags on the java_binary. I was able to get that to work. But I was wondering if there is a way to achieve it from the command line instead of baking it into the java_binary.
java_binary(
...
jvm_flags = [
"-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000"
],
)
Is it possible to achieve this from the command line without hard coding jvm_flags?
Try:
bazel run //:my-target -- --debug
One strategy is to run the build with --subcommands, which will tell bazel to print out all the commands it's running during the build. Then find the command line corresponding to the invocation of the java_binary you're interested in. Then you can copy/paste that command (including the cd part) and modify it to include the debug flags, and debug it as you would any other process.
Note also that java_binary outputs a wrapper script that includes a --debug[=<port>] flag, so that should be all that needs to be added to the command line.
Note also that --subcommands will only print the commands that are actually executed during the build, so a fully cached / fully incremental build will print nothing. You may need to do a clean, or delete some of the outputs of the action you're interested in so that bazel runs that command.
It looks like you can pass the --jvm_flag option as part of the program options after the --.
BUILD:
java_binary(
name = "extract",
main_class = "com.pkg.Main",
resources = glob(["src/main/resources/**/*"]),
)
CLI:
bazel run //:extract -- --jvm_flag="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=7942" -path %cd%\config.json
It seems that the --jvm_flag option needs to come immediately after the --, before the program options (-path in the example). This is with Bazel 3.7.0.
I am trying to determine my testcoverage. To do this I compile my program with a newer version of gcc:
CC=/usr/local/gcc8/bin/gcc FC=/usr/local/gcc8/bin/gfortran ./configure.sh -external cmake -d
After compiling this with the --coverage option I run my tests and this creates *.gcda, *.gcno and *.o.provides.build files. And if I run something like:
> $ /usr/local/gcc8/bin/gcov slab_dim.f90.gcda [±develop ●]
File '/Local/tmp/fleur/cdn/slab_dim.f90'
Lines executed:0.00% of 17
Creating 'slab_dim.f90.gcov'
Which shows me, that gcov runs fine. However if I try to run lcov on these results:
lcov -t "result" -o ex_test.info -c -d CMakeFiles/
I get error messages like these for every file:
Processing fleur.dir/hybrid/gen_wavf.F90.gcda
/Local/tmp/fleur/build.debug/CMakeFiles/fleur.dir/hybrid/gen_wavf.F90.gcno:version 'A82*', prefer '408R'
/Local/tmp/fleur/build.debug/CMakeFiles/fleur.dir/hybrid/gen_wavf.F90.gcno:no functions found
geninfo: WARNING: gcov did not create any files for /Local/tmp/fleur/build.debug/CMakeFiles/fleur.dir/hybrid/gen_wavf.F90.gcda!
This is the same error message I get when I use the systems standard /usr/bin/gcov
This leads me to believe that lcov calls the old gcov rather than the new one. How do I force gcov to use the new version?
The simplest solution I found was to run /usr/bin/gcov-8 instead of /usr/bin/gcov.
The $PATH environment variable needs to be to extended by /usr/local/gcc8/bin/
The source of the error is clear, from the fact that you get the same result by using /usr/bin/gcov. /usr/bin/gcov should be a link to a binary from the installed compiler, but in your case the link doesn't point to a binary within gcc 8.2 installation.
You can delete the link and re-create it to point to the correct gcov or you can setup something like update-alternatives to change the version of gcov when you change the default compiler.
The previous answer should work as well if you have a binary called gcov in /usr/local/gcc8/bin, because if you add that path, into your environment PATH first, it will be selected first.
Some background: I have a project based on ESP-IDF which has a complex builtin building system which you plug into with your own makefile (their documentation on using it).
This works fine (apart from occasional horrendous build times), but now I wanted to add a build target for unit tests for a component, which requires building this component against another project (the unit-test-app).
So, I need another build target that calls another make with another makefile and directory. Something like this works fine:
make -C $(path to unit-test-app) \
EXTRA_COMPONENT_DIRS=$(my component directory) \
TEST_COMPONENTS=$(my component name) \
ESPPORT=$(my serial port) \
-j clean app-flash monitor
But only if I execute it from bash. If I try to execute it from another makefile, it breaks either not finding some header files (the include path is different between the main and unit test project) or ignores the change of project (-C argument) and executes the main project build.
What I tried:
using $(MAKE), $(shell which $(MAKE)) and make in the custom target
using env -i $(shell which $(MAKE) ) -C ... with forwarding required environment arguments to the child make
using bash -l make -C ... and bash -c make -C ...
What works but is a dirty hack: using echo $(MAKE) -C ... in the make target and then running $(make tests) from the command line.
As far as I know, this is an issue of the parent makefile setting something up in the environment that I did not separate the child makefile from. What else can I do to separate these two?
UPDATE: I have created an example project that shows the issue more clearly, please look at the top Makefile of https://github.com/chanibal/esp-idf-template-with-unit-tests
I reproduced your situation as you are describing it and everything works fine, both if I call the inner make from bash or from the outer make.
So there is something you are not telling us that is causing the failure.
On the other hand, I feel there are several irrelevant details in your description.
So, I suggest you try to further isolate the problem, removing irrelevant stuff, and reproducing the problem only from the description in your question, and then when you are doing it you will probably find out what is breaking. If not, then post here the minimal setup with all the other details that are needed for the failure to occur.
By the way, what you are doing is not good practice, so maybe just avoiding it would solve your problems.
What I mean is, there is one case and one case only, where recursive make is good practice: make -C ${directory}
where in directory you have a completely self-contained build, not using anything from the outside.
It seems this is not the case for you, because you seem to be passing some outside location variables. This kind of recursive make is bad practice and should be avoided.
While trying to install a build server I've run into a funny problem where all cygwin commands can be run from a DOS box but sometimes do not work when called from make. What's even more weird is some make targets, like 'clean', work and others, like 'all', do not.
Here's a representative makefile extract. The quoting has hosed the formatting but tabs are where they should be, trust me:
.PHONY: all
all: update_autoconstants
/usr/bin/rm -f $(OBJ_DIR)/myfile1.txt
rm -f $(OBJ_DIR)/myfile2.txt
.PHONY: clean
clean:
rm -f $(OBJ_DIR)/*.*
Notice that in 'all' one rm call has a full path and one has no path. Also notice that clean's rm call has no path.
To this the response to a 'make -C makefile all' is:
/usr/bin/rm -f ../../obj/myfile1.txt
rm -f ../../obj/myfile2.txt
make: rm: Command not found
make: *** [all] Error 127
ie. the full path works, the no-path does not. What then starts my head spinning is the 'clean' target in make with no path works fine. it's not just cygwin commands, make can't find the compiler either. It seems pretty clear that somewhere the path has been hosed, although the environment variable PATH is set, but only in make - this works fine from a DOS prompt.
C:\>cygpath --unix c:\programme\cygwin\bin\rm
/usr/bin/rm
The machine is running Windows Server 2003 German language in a virtual machine on VMWare ESX, the cygwin install was done yesterday, installed in c:\programme\cygwin\ and everything else is clean vanilla Windows installation.
Any ideas? Thanks in advance.
Not really so much of a solution as a workaround - we made all the makefiles use absolute paths to the exe files they need which is in any case a bit nicer than searching a path and taking what you find.
To perhaps save someone some Googling commands in cygwin's bin directory can best be called:
CYGWIN_EXE_PATH = /usr/bin
RM = $(CYGWIN_EXE_PATH)/rm.exe
.PHONY: clean
clean:
$(RM) -f $(OBJ_DIR)/*.*
And similarly files in the program files directory like this:
COMPILER_DIR = "$(PROGRAMFILES)/TASKING/c563 v3.6r1"
Hope that helps.
I've had the exact same thing.
rm not being found by make from within a makefile.
My workaround was to run the makefile from within bash. Previously I was just running make from a windows cmd box. This cured the problem for me, but created new issues. The permissions of some files that were created during the make had very odd permissions being set.
I am running wireshark build on linux. I get a crash,while doing some activities. A core dump is also being generated. But,when i give the following command
gdb ./wireshark core.
It says,file format not recognized. Also,when i do a
cat on "./wireshark",it seems to be some kind of script.
so how to analyze core dumps?
Check the script to see what is the actual wireshark binary being run.
gdb is good for coredump analysis.
when i do a cat on "./wireshark",it seems to be some kind of script.
Probably because you've built Wireshark from source in that directory, in which case it is a script (generated by libtool as a wrapper script).
What you need to do, instead of
gdb ./wireshark core`
is
./libtool --mode=execute gdb ./wireshark core
which will do the right magic to run GDB on the actual executable rather than on the script (and to pass it the right magic to find the shared libraries in your build directory).