I am trying to add a unit test to a group of other tests. All the tests are in their own subdirectories, each with it's own .pro file and the .cpp file which contains the tests themselves. Running qmake in one of the subdirectories creates a Makefile, and then running make runs the compiler to make the TARGET. The tests are actually run by the 'check' target - ie with 'make check'.
The test I'm trying to add is different, but it is trying to pretend to behave the same way.
It is different because it is a perl script and so doesn't need to be compiled. It does, however, need to be run - so 'make check' needs to work.
I had a .pro file working for the most part - 'qmake', 'make', 'make check', and 'make clean' would work, but 'make distclean' removed my script (since it assumes it can be regenerated by compiling something).
So, the question is, how do I stop it from removing my script?
Perhaps there's some other approach I should be taking. I had tried the 'subdirs' TEMPLATE, but that does more than just remove the line in Makefile that deletes the TARGET.
Ideas?
Using Ubuntu Linux with Qt 4.6.0.
I would look into the custom target capabilities for your script. Maybe something like this:
check.commands = <scriptname>
check.depends = <any dependencies>
QMAKE_EXTRA_TARGETS += check
Doing things this way will run the check command when the dependencies change, but as long as you don't specify check.target then it shouldn't remove anything. (If your script does produce output, then perhaps that should be in check.target.) Also, since it is specified as an "extra" command, qmake shouldn't create commands to delete your script in a distclean.
This is assuming that your script is in its own subdirectory (which you state), and is the only "check" command that needs run in that subdirectory (kind of implied by the question, but not directly stated).
Related
I have a script used for CI builds that adds a CONFIG variable to qmake when building via Linux. I need to do the same for Windows desktop devs from within QtCreator. This needs to be an optional (every now and then) thing, rather than the default. Hence why it is not in the .pro file permanently.
Is this possible? And if so, how do I do it?
Edit:
Example of my situation is:
base.pro
SUBDIRS = common base
DESKTOP {
SUBDIRS += app
}
CI {
SUBDIRS += app support_tools
}
Build Script:
#!/bin/bash
qmake -makefile -r -Wall CONFIG+=CI
make
So what I'd like to be able to do is to (occasionally) do the CI style build from within QtCreator. In other words, I just need to be able to pass the additional CONFIG entry to qmake.
Yes, the users could edit the pro file, but that's annoying and has the chance of getting mistakenly committed. It doesn't seem like much of an ask to be able to pass something to qmake from Creator, but I couldn't see where.
You do that in the build settings of the project. You just add CONFIG+=CI in the qmake build step (click the "Details" button to expand it). Once you're done with testing, just remove it again. Or you can create a dedicated CI build configuration that always adds CONFIG+=CI. Although in your case, you probably just want to temporarily add that, build, and then remove it again.
my scenario is: I'm using vim to open some .cpp files, for example
vim 1.cpp src/2.cpp root/src/3.cpp
Sometimes, I wish to rebuild 3.cpp so I have to use another window to
"rm root/src/3.o"
and inside vim, type
":make"
This works fine, NP. But I am looking for a .vimrc function/command that:
When I switch to buffer, e.g. "root/src/3.cpp" and press this command, vim will detect the directory of "root/src" and the file name without suffix "3", and automatically execute a command of "rm root/src/3.o".
In this case, I can casually switch to any buffer and re-trigger the build of this very file.
Note I don't wish to map gmake tool command like "make clean" because we use several different make utilities like scons, cmake, etc.
So how to write this function/command in .vimrc? Thanks.
:call system('rm '.expand('%:p:r')) as #Kent said, or even simply :!rm %:p:r.
But I'm quite surprised you need to do that. Tools in charge of compilation chains usually understand dependencies (which ever the tool is), and you shouldn't need to remove the object file that often to need a mapping to do it for you.
PS: it's perfectly possible (but I need to update the doc) to support CMake, or out-of-source compilation from vim. But indeed, with out-of-sources compilation, you wouldn't need to delete those files manually, a :make clean if :make already works.
you can get root/src/3 from root/src/3.cpp buffer by:
expand('%:p:r')
Then you are free to concatenate the .o to end, and build the command.
I want qmake to run a (python) script automatically. This script modifies the makefiles, so it has to be executed after qmake generates the makefiles but before make.
So far I've only found 2 ways to run a script from qmake:
Using system() in my .pro file, but this runs before qmake - too soon:
win32: PYTHON=python.exe
else: PYTHON=python
system($$PYTHON ./test.py)
or via custom build target using QMAKE_EXTRA_TARGETS, but this is invoked by make (too late).
Is there any way to run a script from qmake after it generates the makefiles?
Since we are using TEMPLATE = subdirs for our project, I solved this by creating new subdir, that is parsed by qmake as a last one. In its pro file I'm using TEMPLATE = aux and running the script by system() call.
It's not the best solution, but it works quite well.
The following has worked well for me for several years.
Create a .cmd or .sh script that invokes qmake, and then your script:
%QTDIR%\bin\qmake %*
python.exe test.py
Save the script where it can be found via the PATH environment
In your .pro file add the following:
QMAKE_QMAKE = myqmake
Then simply invoke myqmake rather than qmake
If the script will be run outside the Qt enviornment, (such as from an IDE), then it may need to define the QTDIR and QMAKESPEC environments.
Cotire (compile time reducer) for CMake might me your friend.
It has the following the feature you're looking for to speed up builds:
Automatically generates a single compilation unit (aka unity source file) for a CMake target.
I did not use it but it is recommended in a C++ best practice list.
I've inherited an Ada/C++ project and I'm trying to use gprbuild to automate the build process (which was previously done with a set of about 12 .bat files). I'm totally new to Ada and gprbuild, but have actually made pretty good progress. I can compile the .exe's that I need, but not the library. I am not at liberty to completely share the .gpr file, but the relevant parts look like this:
[snip]
for Source_Dirs use (
"c_plus_plus_files",
"ada_files",
"..\another_project\some_other_ada_files",
"..\another_project\even_more_ada_files"
);
[snip]
for Source_Files use (
"my_ada_file.ads",
"another_ada_file.ads",
"one_more_ada_file.adb",
"c_plus_plus_file.cpp"
);
[snip]
When I run "gprbuild -P my_project.gpr" it in turn runs "gcc -c gnat5 one_more_ada_file.adb" and complains that it cannot find a certain file that one_more_ada_file.adb depends on. The dependency is in ..\another_project\even_more_ada_files, so I would expect it to be found. But if I copy the dependency into the same folder as one_more_ada_file.adb, the error goes away.
Because of how the VCS is setup and how we're sharing code between two projects, I'd much rather figure out what's wrong with how I'm using "for source_dirs use" than to keep multiple copies of all the ada files.
Again, I'm an Ada/GPS newb, so if I'm leaving out relevant information, please let me know.
Update: It appears that the specific problem isn't that source_dirs isn't doing anything at all, but that it doesn't handle having two source dirs where .ads files in one dir depend on .ads files in the other. That is, even within my "other" project above, an .ads file in some_other_ada_files that depends on an .ads file in even_more_ada_files doesn't get compiled with the gcc -c -gnat05 command when I run gprbuild (error: the file in even_more_ada_files not found), but it does get compiled if I run the gcc command by hand (or in a .bat script) with two -I flags, one for each directory.
When dealing with multiple projects, you should normally create a .gpr-file for each project, and let your projects depend on the other projects as needed.
Thus:
project another_project is
for Source_Dirs use
("some_other_ada_files",
"even_more_ada_files");
end another_project;
and then:
with "..\another_project\another_project.gpr"
project The_Project is
for Source_Dirs use
("c_plus_plus_files",
"ada_files");
end The_Project;
What changes must I make to the .pro file if I want to execute chmod command, execute the output binary file, or do some other operations.
I had a similar problem. I wanted a special tool (versioner) to run over the code every time the Makefile was executed. Here's the solution:
(to be read in the Qmake Manual, Configuring qmake's Environment, Section: Customizing Makefile Output)
Create you own Makefile target. Specify the command etc.
mytarget.target = .buildfile
mytarget.commands = touch $$mytarget.target
QMAKE_EXTRA_TARGETS += mytarget
This way, you have an extra target you can call with make mytarget for example. If you want to tie it together to the actual buildtarget you'll have to add:
POST_TARGETDEPS += mytarget
Hope that helps.
Best regards
D
Another way to make things in given order is to use empty "super" target:
super.depends = target_pre first target_post
QMAKE_EXTRA_TARGETS += super
Where first - is default qmake target, and target_pre and target_post some custom targets. Now make super just do the thing.
EDIT: looks like in last versions of Qt build of dependencies is running in paralell so this solution wouldn't work.
If you are using Qt Creator, you can add custom build steps in the Projects panel: http://doc.qt.nokia.com/qtcreator-2.1/creator-build-settings.html#adding-custom-build-steps
The right answer depends on exactly what you want, and when. However, as seen in some previously posted comments here QMAKE_POST_LINK is probably what you want rather than POST_TARGETDEPS.
Check out this related post:
QMake: execute script after build
For one, when you use POST_TARGETDEPS that fires off BEFORE your exe is created (in Windows) or BEFORE it is recreated (in Linux)! QMake works differently depending upon the platform and the complier.
I needed to do some "symbols processing" on an exe when it was recompiled. POST_TARGETDEPS gave me problems in both Windows (using mingw) and Linux (using gcc). In Windows, it executed my script prematurely, and in Linux it overwrote my exe after I had modified it (i.e. added back my debugging info to the exe after I had stripped it in my external script). QMAKE_POST_LINK worked perfectly, however, in both cases. It's also short, sweet, and more clear by comparison!