I've a make file which runs several of targets , now I want to add new target that will run after some timeout, how can I do it ?
e.g.
execbin: build start run
This is running ok, however I want to add new target called test which will run after two seconds
(some timeout) , how can I do that ?
execbin: build start run test
test should execute after the run has finished and also wait 2 seconds before it start , is it possible ?
The lazy solution would be to add a new target called 'sleep-2', and a pattern rule do:
execbin: build start run sleep-2 test
sleep-%:
sleep $(#:sleep-%=%)
This creates a pattern rule that takes the value after the hyphen in a sleep-<> target, and uses it as the amount of time to sleep.
I will echo #MadScientists's answer that this probably will not work if you do make -j, which really does require changing the targets to depend on each other.
Adding more prerequisites to the list relies on make's behavior that it always tries to build prerequisites in order. While that is a documented requirement of POSIX, so it will always be true, it only works well if you don't use parallelism in your builds (you don't run with -j). If you do, then make can run all of those targets at the same time.
If you want to be sure that a given target does not start until another target finishes, the correct way to do it is declare a prerequisite relationship between them, not add them to the end of a different target's prerequisite list.
So, for example, if you want the test target to not start until the run target is complete, you should declare that:
test: run
run my tests
Now, test cannot be started until run is complete. The simplest way to introduce a sleep is just to put it into the recipe for test like this:
test: run
sleep 2
run my tests
If you want to be more fancy and use a separate target then you need to link the prerequisites, like this:
test: sleep-2
run my tests
sleep-2: run
sleep 2
Unless you have lots of these I think the simple way above is easier to understand.
Related
screenshot
I've just started learning C, so I've been practicing some basic codes.
I pressed F7 to initiate the build, but everything I get is the message like this-
build started...
===========Build: 0 succeeded, 0 failed, 1 up-to date, 0 skipped=========
I waited for over ten minutes and nothing would happen.
I made a new solution with the exact same code, but then it worked without problem.
what would be the problem...?
I wonder if you make any changes to your project Properties such as so that it cannot generate the executable program.
First, right-click on your C++ project Properties-->Configuration Properties-->General--> change Output Directories to $(SolutionDir)$(Configuration)\.
also change Intermediate Directories to $(Configuration)\.
change Target Name to $(ProjectName).
Besides, enter Linker-->General
change Output File to $(OutDir)$(TargetName)$(TargetExt)
After that, delete any Debug or Release,x64 folder under the solution folder and project folder.
Test it again.
We would like to run a Shake build while assuming some target is built, e.g. something like
./Build.hs --dont-rebuild my-target
Reading the docs it seems there should be a way to do that but I can't find it.
The ShakeOptions setting you are looking for is shakeRebuild=[(RebuildLater,"my-target")]. This setting causes Shake to not rebuild my-target in this run. From the documentation of RebuildLater:
This assumption is unsafe, and may lead to incorrect build results in this run. Assume these files are clean in this run, but test them normally in future runs.
This setting can be applied using the command line --skip=my-target. A few caveats:
my-target won't rebuild in this run, by things it depends on might, if they need to.
If you next run without skipping my-target, it will rebuild if it needs to (the --skip is not sticky).
I'm trying to automatically label my application sign-on line with a build number. This application is a plain vanilla C one without graphic UI; it is intended for command line, therefore it is a "simple" one.
The sign-on id is located in a "template" source file which is customized by CMake with a configure_file() command. Recently, I fancied to include a build number in this sign-on id. Consequently, the customization can no longer be statically done at CMake time, but everytime make is invoked.
To achieve that, there are two possibilities in CMake:
add_custom_target(), but it is triggered even when nothing else changes in the source tree which does not reflect the state of the tree;
add_custom_command(), which can be triggered only when the application (target) needs to be linked again.
I opted for the second solution and did not succeed.
Here is an extract of my CMakeLists.txt, the sign-on id being in file ErrAux.c (template in PROJECT_SOURCE_DIR, configured in PROJECT_BINARY_DIR):
add_executable(anathem ... ${PROJECT_BINARY_DIR}/ErrAux.c ...)
add_custom_command(TARGET anathem PRE_LINK
COMMAND "${CMAKE_COMMAND}" "-DVERS=${PROJECT_VERSION}"
"-DSRC=${PROJECT_SOURCE_DIR}"
"-DDST=${PROJECT_BINARY_DIR}"
-P "${CMAKE_HOME_DIRECTORY}/BuildNumber.cmake"
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
COMMENT "Numbering build"
VERBATIM
)
This launches script BuildNumber.cmake just before the link step. It computes the next build number and customizes ErrAux.c with configure_file().
It works fine, except ...
It happens late in the make sequence and the update to ErrAux.c goes unnoticed. The sign-on id in the executable contains the previous build number.
Next time I run make, make notices the generated ErrAux.c is younger than its object module and causes it to be compiled again, which in turn causes a link which triggers a build number update. This happens even if no other file has changed and this loop can't be broken. This is clearly shown in the compiling log:
Scanning dependencies of target anathem
[ 13%] Building C object AnaThem/CMakeFiles/anathem.dir/ErrAux.c.o
[ 14%] Linking C executable anathem
Numbering build
3.0.0-45
[ 36%] Built target anathem
The crux seems to be that add_custom_command(TARGET ...) can't specify an output file like add_custom_command(OUTPUT ...) does. But this latter form can't be triggered in PRE_LINK mode.
As a workaround, I forced a compilation to "refresh" the object module with:
add_custom_command(TARGET anathem PRE_LINK
COMMAND "${CMAKE_COMMAND}" "-DVERS=${PROJECT_VERSION}"
"-DSRC=${PROJECT_SOURCE_DIR}"
"-DDST=${PROJECT_BINARY_DIR}"
-P "${CMAKE_HOME_DIRECTORY}/BuildNumber.cmake"
COMMAND echo "Numbering"
COMMAND echo "${CMAKE_C_COMPILER}" "\$(C_DEFINES)" "\$(C_INCLUDES)" "\$(C_FLAGS)" -c "${PROJECT_BINARY_DIR}/ErrAux.c"
COMMAND "${CMAKE_C_COMPILER}" "\$(C_DEFINES)" "\$(C_INCLUDES)" "\$(C_FLAGS)" -c "${PROJECT_BINARY_DIR}/ErrAux.c"
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
COMMENT "Numbering build"
VERBATIM
)
An explicit compilation is forced after sign-on id customization. It mimics what is found in the various Makefile's and my not be safe for production. It's a cheat trick on both CMake and make.
UPDATE: Option -c is required to postpone link step until the final application liniking process.
This addition creates havoc in the link, as shown by the log, where you see a double compilation (the standard make one and the add_custom_command() one):
Scanning dependencies of target anathem
[ 13%] Building C object AnaThem/CMakeFiles/anathem.dir/ErrAux.c.o
[ 14%] Linking C executable anathem
Numbering build
3.0.0-47
Numbering
/usr/bin/cc -DANA_DEBUG=1 -I/home/prog/projects/AnaLLysis/build/AnaThem -I/home/prog/projects/AnaLLysis/AnaThem -g /home/prog/projects/AnaLLysis/build/AnaThem/ErrAux.c
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
AnaThem/CMakeFiles/anathem.dir/build.make:798: recipe for target 'AnaThem/anathem' failed
make[2]: *** [AnaThem/anathem] Error 1
If I force a full recompilation, to make sure all sources are compiled, *main.c* included, I get the same error on `main`.
The only logical explanation is my manual C invocation is faulty and somehow destroys vital information. I checked with *readelf* that `main` is still in the symbol table for *main.c.o* and that it is still taken into account by the link step (from file *link.txt*).
UPDATE: Even with the correct link, I'm still experiencing the infinite loop syndrom. The generated application still has its sign-on id lagging behind the actual build counter.
Can someone give me a clue for the right direction?
FYI I'm quite new to CMake, so I may do things really wrong. Don't hesitate to criticize my mistakes.
The key to the solution is to put the generated module where make expects to find it. CMake organizes the build tree in a non-trivial way.
The shortcomming in my added compilation in add_custom_command() was to believe that by default the binary will be stored in the "usual" CMake locations. Since I forge manually my compiler command, this is not the case.
I found the module in the source directory, which is a consequence of the WORKING_DIRECTORY option, with name ErrAux.o and not ErrAux.c.o.
To obtain the correct behavior, I force an output location with:
-o "${PROJECT_BINARY_DIR}/CMakeFiles/anathem.dir/ErrAux.c.o"
Now, when I run make again, nothing happens since nothing changed.
Side question
To make the solution portable (if needed), are there CMake variables for CMakeFiles and anathem.dir directories? Or in the latter case, for the current target as "anathem" as the target name in add_custom_command()?
I am trying to make a kernel module loadable on run time. i.e remove it from normal makefile tree compilation, compile it separately and load it via kldload
My configuration:
* I am using freebsd 9.0 stable
* make buildkernel with a standard Makefile
As of now I have no clue how to start with this, googled a bit but no success so far.
So how do I remove my kernel module "module_test" from Makefile and start with separately.
Do i need to change any thing from code also apart from makefiles ?
Any pointers to start of with.
There are several modules in the ports collection. Take a look at their buildsystems.
The portnames usually ends in -kmod; E.g: audio/aureal-kmod, comms/hso-kmod comms/ib-kmod comms/uhso-kmod etc.
What is the best way to compile programs inside emacs? I am currently opening a separate buffer with C-x 3 and running eshell inside it using M-x eshell then invoking either make or clang directly; most of the time I do have a Makefile set up.
Is there any advantage with running the compilation process using M-x compile vs running make inside eshell? Any other ways to do it and what are the advantages/disadvantages of those?
The easiest way to do this is to use the Emacs built-in compile command. M-x compile should do you fine. You can then edit the command that will be run (by default make -k) and then hit return to run the compilation. Emacs will then parse the output and if it finds any errors they will link to the source files so you can open them in a buffer.
Positives about it are:
Parsing of the output buffer
Memorisation of the compile command between invocations
Compilation output is shown in a non-selected buffer, you can quickly edit the file you were working on and fix any silly errors.
M-n and M-p scroll by error messages
Most of these features are provided by the compilation-minor-mode minor mode though not the actual compilation command and buffer. Once you have run a compilation command in eshell you could probably get similar results by setting the minor mode to compilation-minor-mode.
I personally prefer to run make or whatever command you're using to
compile within a multi-term
for the following reasons:
it works like M-xcompileRET if you activate
compilation-shell-minor-mode (M-p, C-`, …).
but you can, obviously, use other commands like
mkdir build
cd build
./configure --with-another-option
Of course you can do this from Emacs but I prefer the shell
interaction for this kind of stuff.
And imo, the main drawback of M-xcompile is that if
you're editing a file located in another directory than your
Makefile then you have to use M-xcompile in the correct
directory and then M-xrecompile. But if you want, say to
make clean && make, then you'll have to switch to the correct
directory, do it, switch back.
However term.el has its own drawback, it uses a non-portable hacky
way to track the current directory.