I am trying to build a software following some instructions on line.
cd app
mkdir -p build/Release
cd build/Release
cmake ../..
make installpyplusplus && cmake .
make .
My questions:
What does "../.." after cmake do or mean?
What is the significance of the dot after make?
what will 'make installpyplusplus && cmake .' ?
The cmake application looks for one file in special, called CMakeLists.txt.
So by running:
cmake ../..
It's like saying to cmake that the CMakeLists.txt is two directories below, like described by MERose.
The cmake command creates many files at your current working directory (CWD, the directory you ran the command from), and among them is a file called Makefile, which has rules about which files to compile/build/copy/write/whatever and how to do it.
So when you run:
make .
You are telling the make application that the Makefile file is at your CWD. It's the same as running:
make
That looks for the Makefile file at your CWD.
Concluding, . is the CWD, and .. is one level below.
EX: If your CWD is /Users/yourname/
. represents /Users/yourname/
.. represents /Users/
../. represents /Users/
../.. represents /
And so on...
what will 'make installpyplusplus && cmake .' ?
When you use && the commands will be executed sequentially if the first command returns true (exit status zero). So, in the case you said, make installpyplusplus will be run, and after it's done (it can create a CMakeLists.txt, I don't know what you are running), if it returns true, the command cmake . will be run, and if the CMakeLists.txt is there, it will run properly.
BONUS:
If you run:
make -j4
You will separate the build process in 4 instances (you can change 4 by anything you want)! Multi-threading magic will make it build faster if you have more than one processor core available :)
Related
I'm trying to write a Makefile in such a way that all of the steps in my recipe can call scripts a list of directories. As an example, I have node commands that are in a node_modules/.bin directory, but there could just as well be Python commands from a Python virtual environment as well, etc.
I have node installed, as well as TypeScript installed via npm in my /node_modules. Given my directory /tmp/test123, I wrote the following Makefile at /tmp/test123/Makefile as an example:
PATH = /tmp/test123/node_modules/.bin:$(PATH)
.PHONY: compile
compile:
env | grep "PATH"
tsc --help
However, if I try to run it, it outputs:
$ make compile
env | grep "PATH"
PATH=/tmp/test123/node_modules/.bin:... # the rest of my PATH
tsc --help
make: tsc: No such file or directory
make: *** [compile] Error 1
But if I change the last line to cd . && tsc --help, then compile runs successfully.
Why is make unable to find the tsc command in the PATH? Why do I need to run cd . && in front of it? Is there any better workaround than writing cd . && in front of all of my recipe steps?
I know the common way to generate a CMake project dependencies graph by the CLI:
cmake --graphviz=[file]
But is there a way for it to be autogenerated by just setting a flag or command within a CMakeList? The idea is for the CMakeLists.txt itself to trigger the graph generation, and not the user through command line.
You could call CMake inside your script again, e.g. like:
add_custom_target(graphviz ALL
"${CMAKE_COMMAND}" "--graphviz=foo" .
WORKING_DIRECTORY "${CMAKE_BINARY_DIR}")
Not only can you create a CMake custom target for running Graphviz, but you can take it a step further, and have it also generate the image files for you using Dot:
add_custom_target(graphviz ALL
COMMAND ${CMAKE_COMMAND} "--graphviz=foo.dot" .
COMMAND dot -Tpng foo.dot -o foo.png
WORKING_DIRECTORY "${CMAKE_BINARY_DIR}"
)
This way, the custom target runs the second command dot -Tpng foo.dot -o foo.png as well. You can output the image files anywhere on your system by pre-pending foo.png with a path of your choosing.
Is there a concise doc or example for how to use an existing QMake project with .pro project file as an "external project" in CMake? This can somewhat be done in qtcreator by marking one project as dependency of another, but it would be nice to define it more explicitly with the ExternalProject() CMake syntax.
related question: CMake: How to build external projects and include their targets
Something like this works. You can then edit the files from either qtcreator in main CMake project tree, OR from opening the .pro file; great for iterating quickly on QT widgets in SomeGarbageApplication that is part of large cmake build tree.
macro(DeclareProjectFiles Tag Filez)
######### Trick: use this syntax to make arbitrary files
######### appear in IDE project. #######################
### Note: pass in the raw name of a list variable,
### since it will get expanded here in this macro.
add_custom_target(${Tag}_files ALL
pwd
COMMAND ls -ltrh
COMMENT " ${Tag} files thunk... got list: [ ${${Filez}} ]"
VERBATIM
SOURCES ${${Filez}}
)
endmacro()
message(STATUS "QT_QMAKE_EXE is: ${QT_QMAKE_EXECUTABLE}")
set(Z SomeGarbageApplication)
file(GLOB ${Z}_Files
./*.cpp
./*.h
./*.ui
./*.pro
./*.png
./*.jpg)
DeclareProjectFiles( ${Z}_grbg ${Z}_Files )
add_custom_target(${Z}_pro ALL)
set(ExtraQMakeArgs -r -spec linux-g++ CONFIG+=release)
# note: use killall because this can/will fail if the exe is running
# But, need || true to not fail build when it's not running.
add_custom_command(TARGET ${Z}_pro
COMMAND killall
ARGS -q -9 -v ${Z} || true
COMMAND ${QT_QMAKE_EXECUTABLE}
ARGS -query
COMMAND ${QT_QMAKE_EXECUTABLE}
ARGS ${CMAKE_CURRENT_SOURCE_DIR}/${Z}.pro ${ExtraQMakeArgs}
COMMAND make ${Z}
ARGS -j4
COMMAND cp
ARGS ${Z} ${CMAKE_CURRENT_SOURCE_DIR}/${${Z}_config} ${CMAKE_BINARY_DIR}/bin/
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
VERBATIM
)
#################################################################
I'm kinda a new to writing spec files and building RPM's. Currently I have one RPM that is supposed to deploy some files in 1 of 2 possible directories that will vary with the OS.
How can I, within the %files section, verify them? I can't use variable...I can't verify both paths because one will for sure fail...I tried to define a macro earlier in the %install section but it will be defined just once and won't be redefined on every RPM installation...
what can I do here?
Thanks
I had a similar situation where additional files were included in the RPM in case of a DEBUG build over and above all files in the RELEASE build.
The trick is to pass a list of files to %files alongwith a regular list of files below it:
%install
# Create a temporary file containing the list of files
EXTRA_FILES=$RPM_BUILD_ROOT/ExtraFiles.list
touch %{EXTRA_FILES}
# If building in DEBUG mode, then include additional test binaries in the package
%if %{build_mode} == "DEBUG"
# %{build_mode} is a variable that is passed to the spec file when invoked by the build script
# Like: rpmbuild --define "build_mode DEBUG"
echo path/to/file1 > %{EXTRA_FILES}
echo path/to/file2 >> %{EXTRA_FILES}
%endif
%files -f %{EXTRA_FILES}
path/to/release/file1
path/to/release/file2
In your case, you can leverage the %if conditional in the %install section, use the OS as a spec variable passed to rpmbuild (or detect it in the RPM spec itself) and then pass the file containing the list to %files
The %files section can have variables in it, but usually this would be something like your path that is defined so you don't have to repeat it a bunch. so %{long_path}/file_name, where long_path was defined earlier in the spec file. the %files section is all the information that goes into the RPM database, and is created when you build the RPM so you won't be able to change those values based on machine information when installed.
If you really want to do this, you could include a tar file inside of the main tarball that gets extracted depending on certain conditions (since the spec file is just bash). Now keep in mind this is an awful idea. The files won't be tracked by the RPM database, so when you remove the RPM these files will still exist.
In reality you should build two RPMs, this will allow for better support going forward into the future in the event you have to hand this off to someone, as well as preserving your own sanity a year from now when you need to update the RPM.
This is how I solved my problem
step 1 :
In Build section .. somewhere I wrote :
%build
.....
#check my condition here & if true define some macro
%define is_valid %( if [ -f /usr/bin/myfile ]; then echo "1" ; else echo "0"; fi )
#after his normal continuation
.....
...
Step 2: in install section
%install
......
#do something in that condition
if %is_valid
install -m 0644 <file>
%endif
#rest all your stuff
................
Step 3:in files section
%files
%if %is_valid
%{_dir}/<file>
%endif
That's it
It works.
PS : I cannot give you full code hence giving all useful snippet
Forrest suggests the best solution, but if that is not possible practical you can detect the OS version at runtime in the post-install section, move the script to the appropriate location, and then delete it post-uninstall, eg:
# rpm spec snippets
%define OS_version %(hacky os detection)
...
Source2: script.sh
...
%install
install %{_sourcedir}/script.sh %{buildroot}/some/known/location
...
%post
%if %{OS_version} == "..."
mv /some/known/location/script.sh /distro/specific/script.sh
%elif %{OS_version} == "..."
...
%preun
rm -rf /all/script/locations
Much more error prone than building different RPMs on different OSes, but will scale a little better if you need to support many different OSes.
I am using cmake to build my project. For UNIX, I would like to type make from my project's root directory, and have cmake invoked to create the proper Makefiles (if they don't exist yet) and then build my project. I would like the cmake "internal" files (object files, cmake internal Makefiles, etc.) to be hidden (e.g. put in a .build directory) so it doesn't clutter my project directory.
My project has several sub-projects (in particular, a library, a user executable, and a unit test executable). I would like Makefiles (i.e. I type make and this happens) for each sub-project to execute cmake (as above) and build only that sub-project (with dependencies, so the library would be built from the executables' Makefiles, if needed). The resulting binary (.so library or executable) should be in the sub-project's directory.
I made a Makefile which does the main project bit somewhat well, though it feels somewhat hackish. I can't build specific targets using it, because my Makefile simply calls make in cmake's build directory.
Note that because the library is a sole dependency (and probably doesn't need to be build manually, and because I'm lazy) I omitted it in my Makefile.
BUILD_DIR := .build
.PHONY: all clean project-gui ${BUILD_DIR}/Makefile
all: project-gui project-test
clean:
#([ -d ${BUILD_DIR} ] && make -C ${BUILD_DIR} clean && rm -r ${BUILD_DIR}) || echo Nothing to clean
project-gui: ${BUILD_DIR}/Makefile
#make -C ${BUILD_DIR} project-gui
#cp ${BUILD_DIR}/project-gui/project-gui $#
project-test: ${BUILD_DIR}/Makefile
#make -C ${BUILD_DIR} project-test
#cp ${BUILD_DIR}/project-test/project-test $#
${BUILD_DIR}/Makefile:
#[ -d ${BUILD_DIR} ] || mkdir -p ${BUILD_DIR}
#[ -f ${BUILD_DIR}/Makefile ] || (cd ${BUILD_DIR} && cmake ${CMAKE_OPTS} ..)
If it helps, here's my project structure (if this is "wrong" please tell me -- I'm still learning cmake):
project/
project/CMakeLists.txt
project/common.cmake
project/Makefile -- see Makefile above for this; should be replaced with something better, building libproject, project-gui, and project-test
project/libproject/
project/libproject/CMakeLists.txt
project/libproject/libproject.so -- after build
project/libproject/Makefile -- doesn't exist yet; should build libproject only
project/libproject/source/
project/libproject/include/
project/project-gui/
project/project-gui/CMakeLists.txt
project/project-gui/Makefile -- doesn't exist yet; should build libproject then project-gui
project/project-gui/source/
project/project-gui/include/
project/project-test/
project/project-test/CMakeLists.txt
project/project-test/Makefile -- doesn't exist yet; should build libproject then project-test
project/project-test/source/
project/project-test/include/
If you haven't caught on yet, I'm basically looking for a way to build the project and sub-projects as if cmake wasn't there: as if my project consisted of only Makefiles. Can this be done? Is the solution elegant, or messy? Should I be trying to do something else instead?
Thanks!
If cmake is generating the makefiles, you can simply include the generated makefile in the master makefile, eg
# makefile
all: # Default
include $GENERATED
$GENERATED:$CMAKEFILE
# Generate the makefile here`
The included files are generated then make is restarted with the new included files. The included files should detail the targets, etc.
You should be able to change the location of used files using the vpath directive, see e.g. the Gnu make manual,
vpath %.o project/.build
else the tedious way is to rewrite the rules making note of the necessary directory.
Ed:
Perhaps we shouldn't use a flat makefile.
Try something like:
# makefile
all: gui test
clean:
$(MAKE) -f $(GUI-MAKE) clean
$(MAKE) -f $(TEST-MAKE) clean
gui:$(GUI-MAKE)
$(MAKE) -f $(GUI-MAKE) all
$(GUI-MAKE):$(GUI-CMAKE)
# Generate
# Same for test
This should work if the $(MAKE) -f $(GUI-MAKE) all command works on the command line, and we've hidden cmake in the generating target. You would have to copy any other targets to the master makefile as well, and take care running make in parallel.
Propagating object files through should involve something like
%.o:$(GUI-MAKE)
$(MAKE) -f $(GUI-MAKE) $#
although you'll probably get errors trying to make test objects