I would like my nmake output to go to a particular directory.
The short bit is that there isn't such a thing as Make and configure do two different things. The configure is what creates a Makefile, and a Makefile is what actually contains the compiler commands to build the software. Together they create what is called a build system. To specify the target directory, you'll need to review what creates that makefile for you. However, if you do not generate a Makefile, it is likely that there is a variable which you can override with your target directory, something like:nmake DESTDIR="Path"
With your added comment regarding your file, if it's set-up like this project, then you'll can use nmake PREFIX="Path"
Related
I have a project which uses CMake. Most of the project builds with CMake, but there's one subdirectory with a complicated build procedure that doesn't work with CMake. For this one directory, we have a hand-written Makefile. To build this one special directory, we manually copy it over to the build directory and call make on it after we've called cmake && make to build the rest of the project.
What I want CMake to do is just copy over this one directory to the build directory as is, with its existing Makefile, without trying to generate a Makefile. Then when I call make on the top level build directory, it just invokes the hand-written Makefile for this one directory. Is this possible?
I short: Yes, this is possible.
Steps:
Copy the Directory
Add the Makefile as a build step using either add_custom_target or add_custom_command depending on the purpose of the makefile
I am now using cmake to compile and build a C++ project on multiple platforms. Every time the cmake script is called, everything in the building folder is deleted. For example, I use the following shell command to illustrate the way how cmake is called:
rm -rf build_folder
mkdir build_folder
cd build_folder
cmake ..
By doing so, we are sure that the library or binary produced by the project is updated with regard to the source code. However, it may take time as every time camke will call the compiler to build the project from scratch. The reason lies in the fact that we are concerned that cmake may keep some intermediate results from the previous build if we do not delete everything in the building folder. So my question is: are our concerns justified and if just call cmake .. in the previous building folder without deleting anything in the folder what kind of danger can we have?
A major point of using a build system is not having to rebuild everything every time. A correct build system correctly tracks which files have changed and what commands are therefore necessary to do a correct, minimal rebuild.
If that doesn't work for you, you have messed up your build system.
If you are worried about doing builds for different platforms, and the build system not recognizing the difference, that's just one way your build system is messed up. Specifically, the problem is that you are building different variants, sequentially, in the same directory. At least that's what I take from your description. That's stupid, don't do it. Use a different build folder for every platform, call cmake once in each folder with the correct configuration, and then leave it be.
I got the Box2D project source and want to compile the testbed portion of it.
The project folder contains folders like: freeglu glui testbed(a demo) helloword(a demo)
Box2D Build CMakeFiles
There are many CMakeLists.txt in all the different folders.
I was thinking that I should cmake all those files so that make files are created in all places required.
I read this (as instructions to do do want I want) :
wget http://box2d.googlecode.com/files/Box2D_v2.2.1.zip
unzip Box2D_v2.2.1.zip
cd Box2D_v2.2.1/Build
cmake ..
make
What does the cmake .. do?
There is no CMakeLists.txt in the build folder.
cmake is a Makefile generator.
When you call cmake [path], you ask it to generate a Makefile in the current directory following instructions given in [path]/CMakeLists.txt
Usually cmake output some messages while it is working, and after it is done without errors, you can type "make" to execute your newly created Makefile.
CMakeLists.txt files can reference other CMakeLists.txt file in sub-directories, so you are usually only interested by the CMakeLists.txt of the top directory, not the other ones.
Using an empty "build" directory is a technique called "out-of-source build", in which all your generated files (.o, executable, Makefile, .anything) are generated in the separate "build" directory and not mixed with source files. If you want to clean all, you can delete all the content of the build directory.
In fact, you can put your "build" directory in any place, as long as you give cmake the correct path of the top CMakeLists.txt. You can even have several build directories. It is very useful if you need several different builds at the same time (with different options, different versions of gcc, etc.)
In old programs, you generate the Makefile too, but using ./configure (this is called auto-tools. You may have encountered that already). cmake is considered a successor of the auto-tools.
cmake .. generates makefiles in the current directory, using ../CMakeLists.txt file as starting point. make command, executed after this, builds the program, using generated makefile(s) as an input. This is convenient to keep a source code and build results in different folders. General syntax is: cmake source-dir (of course, there are a lot of other switches).
Well, .. is shorthand for the parent folder, so it will presumably act upon whatever it finds in Box2D_v2.2.1.
I have a big project that uses CMake to create Make file. Sometimes, I add one small project and then have to run the CMake script for whole project (like delete previous, and create newer CMake with this project included).
I was wondering, whehter there is some option in CMake whereby I can only "update" the Make script (created by CMake) to include newly added project (rather than above option).
Thanks,
You can only do
cmake .
in directory which contains CMakeCache.txt. This will trigger whole reconfiguration, but save your options.
Question: Can CMake generate build scripts that do not, in any way, use CMake? If not, how hard is it to gut a CMake generated automake script to not make any checks against CMake?
I am a big fan of CMake to the point where I am championing the idea that we transition to it in my current work environment. One thing that could ease this transition from our current build system to CMake would be if I could demonstrate that CMake can generate automake files that do not require cmake themselves.
Clearly, I would never want to do this for day to day use, but having the ability to easily create a branch of our code that can be built from source without requiring cmake would go a long way in helping me make my case.
The ability to do this depends on your OS, I'm presuming Unix/Makefile or Windows/MSVC. If you're using MSVC, the cmake dependency should be eliminated by declaring the CMAKE_SUPPRESS_REGENERATION option at the start of your cmake script.
SET(CMAKE_SUPPRESS_REGENERATION TRUE)
On Unix-based systems, however, the Makefiles are tied explicitly to the cmake build files (CMakeFiles, etc). I suspect that this dependency could be bypassed by the strategic commenting out of Makefile directives although, I cannot say what they might be.
No, CMake cannot do this. It doesn't really make sense, either, since without any CMake-support at build-time, there would be no way to check or update the makefiles/project-files themselves when the CMakeLists.txt files have changed.
If you are moving from Visual Studio to CMake, you may want to take a look at vcproj2cmake.
CMake generated files depend on cmake for various commands such as create / remove / etc... not just to regenerate the makefiles on a change so removing cmake is not going to work.
As someone who has taken a large complex piece of software and recently pulled out its existing build system, installing a new build system in its place. I can tell you that it's not easy, but I would definitely not want shell scripts as part of my build process, if they can be avoided. More and more systems will find themselves with CMake on them anyway, as more big name software packages like LLVM and KDE start using it—This is an area where it really accels, large projects.
One of the nice things about CMake is it builds things quicker. Resorting to have to fork shell instances to interpret a script really slows down the build process.
What about the 'atomic solution' ?
EX- auto-generate a "QT moc" file from CMakeLists.txt, then build project that depends on the .cpp file being generated
# inside project level CMakeLists.txt
# run shell script to create the "moc_GUICreator.cpp" auto-generated source file
if(UNIX)
execute_process(COMMAND "sh" ${CMAKE_CURRENT_SOURCE_DIR}/scripts/generate_moc.sh WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scripts )
endif(UNIX)
Where the .sh file contains:
# generate_moc.sh
echo "generating moc file: moc ../include/GUICreator.h -o ../src/moc_GUICreator.cpp "
moc ../include/GUICreator.h -o ../src/moc_GUICreator.cpp
Equivalent windows batch file, "moc_creator_win.bat":
moc "GUICreator.h" -o "moc_GUICreator.cpp"
Haven't tried this last bit in windows, but it or something very close should work, just after the if(UNIX) block in CMakeLists.txt:
if(WIN32)
execute_process(COMMAND "cmd" ${CMAKE_CURRENT_SOURCE_DIR}/scripts/moc_creator_win.bat WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scripts )
endif(WIN32)
So, basically if you're clever you can do whatever you want from a script and use CMake variables as args to it, I'm not sure if you can ask for more...
the point is to avoid 'non-portable build types' unless you really need to hack it into a specialized compiler, or don't feel like using QT Designer to place the widgets ;-)