1. cmake is a command from CMake software: preparation for build automation system; make and make install are commands from Make software: build automation system.
2. From reading this post, what I understand is that:
a. This "cmake and make" stuffs actually use g++ / gcc in its implementation. cmake and make stuffs are basically just tools in using g++ / gcc. Is that correct?
b. gcc / g++ are the compiler that do the actual work.
c. So I can just use gcc / g++ directly without using the make and CMake things?
3. According to this stackoverflow answer: CMake takes a CMakeList.txt file, and outputs it to a platform-specific build format, e.g., a Makefile, Visual Studio, etc.
However when I came across this openCV installation :
mkdir release
cd release
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local ..
It executes cmake command in a directory where there is no CMakeLists.txt file. Can you explain and elaborate on this?
4. The usual steps that I've seen are: cmake, make, sudo make install.
I read this stackoverflow post, what I understand:
(i) make is for building the project.
(ii) make install is to copy the binary / executables to the installed directories.
a. So when we make, where are the result / binary files / executables stored at?
b. If we only run make without make install, does it mean that the files are not generated?
c. I came across this openCV tutorial on using openCV with GCC and CMake. It uses:
cd <DisplayImage_directory>
cmake .
make
Why doesn't it do make install as well?
5. In summary:
CMake takes CMakeList.txt file (which is cross platform) to generate a Makefile (which is specific to a platform).
I can just write Makefile manually and skip the CMake step. but it is better to do with the CMake step because it is cross platform, otherwise I have to rewrite the Makefile again if I change platform.
Make takes Makefile (which is generated by CMake or written manually) as a guide to compile and build. Make basically uses gcc / g++ or other compiler in its work. Make itself is just a tool for the compiler.
Make install put the result / executables into the install path
CMake generates files for other build systems. These can be Makefiles, Ninja files or projects files for IDEs like Visual Studio or Eclipse. The build files contain calls to compilers like GCC, Clang, or cl.exe. If you have several compilers installed, you can choose one.
All three parts are independent. The compiler, the build system and CMake.
It is easier to understand when you have the history. People used their compiler. Over time they added so many flags, that it was cumbersome to type them every time. So they put the calls in a script. From that the build systems (Make, Ninja) evolved.
The people wanted to support multiple platforms, compilers, scenarios and so on and the build system files became hard to maintain and their use was error-prone. That's the reason people invented meta build system that creates the files for the actual build system. Examples are Autotools or CMake.
Yes
CMake does not use your compiler, make does not implement it, but it calls (uses) the compiler.
The CMakeLists.txt file should be in the parent directory of release. The last argument of the CMake call indicates the path where the CMakeLists.txt file is located.
Right, make generates the file in the build directory. In your example from 3. release is the build directory. You can find all the generated files and use them. Installing is optional, especially if you want to develop the software, you are not installing it.
Try writing Makefiles for a large project and you will see how much work it is. But yes, everything in 5 is right.
I have a small project that requires a few standard libraries, say libpng and boost. For now I hope that project can build easily on any of my collaborators machines (OSX/Unix/Linux), but am not concerned packaging or installing it right now. My question is, is there an easy way to write "home-brewed" Makefile or configure file that can automatically find and use those libraries on a particular *nix system?
I know Autoconf and CMake are tools designed for such tasks, but I and my collaborators do not want to go into the fuss for such a small project, at least not right now.
Another possibility I have in mind is pkg-config. Is that a recommended approach? I currently have two problems with that: (1) it cannot find all libraries, (say boost, discussed here, here and here), and (2) not all system seems to have installed pkg-config.
The solution I hope to have ishave in mind is to write a Makefile that looks like below.
INCpng = $(shell command retrieves "-I/path/to/png.h")
LIBpng = $(shell command retrieves "-L/path/to/libpng.so -lpng")
INCboost = $(shell command retrieves "-I/path/to/boost")
LIBpng = $(shell command retrieves "-L/path/to/libboost.so -lboost")
SomeFile: SomeFile.cc
$(CXX) $(CXXFLAGS) $(INCpng) $(INCboost) $(LIBpng) $(LIBboost) -o $# $<
I'm also open to write a not-to-complicated configure file.
pkg-config was designed for more-or-less exactly this purpose. It was designed to replace the X-config scripts/etc. that many projects had been writing on their own before that.
I don't know about CMake but I believe the autotools are just using pkg-config internally.
For things that pkg-config cannot find (and that do not have their own X-config) the only thing you can do is use reasonable defaults and allow people to over-ride them (you could test some common alternatives as fallback defaults as well but you still need to allow user over-riding.
I have a project written in gcc - bison -flex on Linux environment. All the project is implemented into a *.so file and is called from python-tkinter graphic surface.
There is a need to run it on windows. However I'd avoid to install all the windows equivalent of gcc - bison -flex programs.
Is it possible to force gcc IN LINUX ENVIRONMENT to compile WINDOWS DLL instead of *.so? It could make life easier to use the same technics as I do now: just do calls from python-tkinter graphic surface.
You can, of course, cross-compile it.
You'll need some packages installed, though.
Your normal project would be able to build if you use the MINGW equivalent of GCC for the target architecture.
Also, take a look at this:
Manual for cross-compiling a C++ application from Linux to Windows?
The linking can be kind of troublesome though, since it could come a time where softlinking fails due to versions. In that case you'll need to create some symbolic links to the correct version.
The output of the compilation process should be with -o DYNAMIC-LIBRARIE-NAME.dll and of course use the -shared flag.
Hope it gives you some pointers..
Regards.
Under cygwin, with libtool I am trying to link a static library. the --mode=link cl.exe line invokes ar cru on the .obj files to create the .lib. However, I know there's another program under windows, LIB. As far as I understand, it's equivalent to ar, but will it make any difference in using ar+ranlib vs. LIB, and how can I force libtool to use LIB instead of ar?
Since setting AR and AR_FLAGS won't work, the only easy solution (that I haven't tried) is CCCL which wraps up cl.exe and link.exe for a neater interface to those programs for autoconf packages. It looks kind of old now, but it might work.
The installation instructions assume that CC/CXX are going to be cl.exe, but you're probably using GCC. In that case, probably AR=cccl needs to be an argument to configure.
I'm having trouble building the hmatrix library on OS X Lion. Looking at the .cabal file, it requires the gsl library, so I installed it with macports. The .a files are in /opt/local/lib and the .h files are in /opt/local/include/gsl
As suggested here I changed the built-type from Custom to Simple. (without that change I get a similar error).
When I use cabal configure I get the following output:
* Missing C library: gsl
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
So I tried cabal --extra-include-dirs=/opt/local/include --extra-lib-dirs=/opt/local/lib configure, but I still get the same error. I can compile and link a c program that includes gsl. What files is cabal looking for? If I have the right files, how do I tell it how to find them?
libgsl.a is a universal binary:
$ file /opt/local/lib/libgsl.a
/opt/local/lib/libgsl.a: Mach-O universal binary with 2 architectures
/opt/local/lib/libgsl.a (for architecture x86_64): current ar archive random library
/opt/local/lib/libgsl.a (for architecture i386): current ar archive random library
ghc looks like it's 64-bit:
$ ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv")
,("C compiler command","/usr/bin/llvm-gcc")
,("C compiler flags"," -m64 -fno-stack-protector -m64")
,("ar command","/usr/bin/ar")
,("ar flags","clqs")
,("ar supports at file","NO")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("perl command","/usr/bin/perl")
,("target os","OSDarwin")
,("target arch","ArchX86_64")
,("target word size","8")
,("target has GNU nonexec stack","False")
,("target has subsections via symbols","True")
,("Project version","7.4.2")
,("Booter version","7.4.2")
,("Stage","2")
,("Build platform","x86_64-apple-darwin")
,("Host platform","x86_64-apple-darwin")
,("Target platform","x86_64-apple-darwin")
,("Have interpreter","YES")
,("Object splitting supported","NO")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Unregisterised","NO")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn")
,("Leading underscore","YES")
,("Debug on","False")
,("LibDir","/usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2")
,("Global Package DB","/usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2/package.conf.d")
,("Gcc Linker flags","[\"-m64\"]")
,("Ld Linker flags","[\"-arch\",\"x86_64\"]")
]
As an alternative to mac-ports you can use the nix package manager for mac. It does a pretty good job of taking care of the c dependancies for for the libraries available through it. In general I have been more happy with it then any other package manager on mac.
Unfortunately mac(darwin) unlike for linux does not have as many binaries available through nix so installing ghc often means waiting for it to compile.
The commands to install ghc and hmatrix after installation of nix are:
nix-env -iA nixpkgs-unstable.haskellPackages.ghc
nix-env -iA nixpkgs-unstable.haskellPackages.hmatrix
All of the needed dependencies will be taken care of for you.
I just tried it on my macbook pro and hmatrix seems to be working correctly in ghci after trying commands from the first few pages of the tutorial.
I'm not a mac person, but it really sounds like you haven't installed the "-dev" version. For a mac, I suspect you need to install gsl-devel in addition to gsl. If the problem persists, verify that you have libgsl0-dev on your library path.