I started working with CMakeLists a few days ago and I can't quite figure how to include an external library (.h + .dll/.lib files) to my project and sub projects. Any tips and tricks would be much appreciated!
What I want to do is to include a bunch of external libraries (listed in title) to my projects. Plus I'm not sure if I want to do static or dynamic linking.
This is my current file structure:
And this is my CMakeList so far...
As I said, the problem is that I don't quite grasp CMake yet.
Related
I have an Eclipse project that is currently a monolithic one. That is, it contains all of the C source/includes and build an executable. This project is comprised of a GIT module and several submodules. I would like to refactor this Eclipse PROJECT so that it contains the executable project and projects for the submodules as static libraries.
I'm pretty sure that I can do this if I was creating this from scratch. However, I can't seem to figure out how to do this by modifying the existing project.
Any ideas on how to accomplish this?
I am starting to learn about CMake and have two questions:
1. Do I need to update the CMakeLists.txt file every time When I add a new file?
Assuming that the size of the project grows, the number of subdirectories and source files in the project will also increased greatly.
In such a case, I guess it is inconvenient to update the CMakelists.txt file whenever a new file or directory is added to the project.
Or is it part of the code management? How is it usually done?
2. In order to build a C Eclipse project(makefile) using CMake, should I write the CMakeList.txt manually?
There are many ways to import CMake projects into Eclipse, but I can't see how to build a C Eclipse project with CMake.
Do I need to update the CMakeLists.txt file every time When I add a new file?
CMake, like GNU make, allows to use wildcards to specify source files.
However, it's good practice to explicitly list files to build, in order to avoid silly mistakes (due, for example, to missing or unexpected files in source directory).
When file list becomes large, build definition files (like CMakeLists.txt) may be split into multiple files.
In order to build a / C Eclipse project(makefile) / using CMake, Should I write CMakelist.txt manually?
I don't know aboud Eclipse, but many IDEs partially/completely automate CMakelists.txt creation. Maybe Eclipse has such a tool too.
Yes write your CMakeLists.txt manually. This can barely be automated, beside adding new header files. There is a way to include all *.h files, but it is not enouraged.
And add every new header file manually. C files are not needed. Adding header files should not happen ofen.
Writing your own CMakeLists.txt files is recommended (at least you understand how CMake works). However, for larger projects it makes sense to automate it. I decided to post my own CMake generator https://github.com/Aenteas/cmake-generator so anyone who wants to implement their customized version could adopt some ideas from here (as it is not likely that my generator would suit your needs perfectly).
I am moving from Netbeans to Eclipse (on Ubuntu 12.0.4). I have a C application that consists of several sub projects which are libraries (shared and static), as well as stand alone executables.
I can't figure out how to create a 'parent' project foo, which contains component projects
foobar
foofoo
barfoo
barbar
Ideally, I want all the 'component projects' to be created under the folder foo, so that I have a directory structure like this:
/path/to/foo/foobar/ (contains foobar project files)
/path/to/foo/foofoo/ (contains foofoo project files)
/path/to/foo/barfoo/ (contains barfoo project files)
/path/to/foo/barbar/ (contains barbar project files)
Does anyone know how I can achieve this structure using Eclipse as IDE (with CDT)?
Last but not the least, I intend to create my C modules using the Autotools option. Will the generated files for Autotools be automatically updated as I add new header/source to a module - or do I need to manually maintain the Autotool files?
Friend,
I think there is no the "parent" C project. You can create a normal C project in IDE and add all dependencies into sub-folders. Then tell compiler your build procedure via Makefile. I think it's easy way as you have had experience on C application.
About autotools, once you update/add/remove your project file, I think you need to modify your Makefile to reflect your change and do clean and rebuild your project.
For other C build tools, you can use buildroot if you'd like.
The best way I can think to do this in eclipse is to create a separate workspace for the project e.g. foo, and then add the sub-projects (foobar, foofoo, etc...) as projects. This is generally a better approach to take with eclipse, instead of a single monolithic workspace. I don't know what the specific dependency structure for the sub-projects looks like, but you should be able to express it simply by using eclipse project properties. This can include a rollup executable sub-project that depends on the libraries.
Unfortunately, I'm not sure if eclipse cdt will maintain autotools files. However if not, it should be relatively easy to integrate and use some of the autotools binaries such as autoscan, and autoheader into the eclipse build commands.
At first you need to a working directory, Then you should new project, Then per file or per class (according to C++ or C ) append your files, it's much safe way. another way is not clean, i have experience. don't use them.
I inherited a project written in C, running on Linux, with Cmake files written by the previous person. The previous person did not use IDE for this project, so I found it a bit hard to maintain this fairly large sized project, and I'm new to Cmake unfortunately :(.
I want to use eclipse (my OS is Linux) for this project to help me understand the project faster, and be able to build and debug it in Eclipse, so I do not have to run the build scripts manually every time. The project was in Mercurial, hence I check it out into my repository using Eclipse, then I have some options:
Open the project, and somehow make it into a C project which I can compile
Convert the code into makefile project, use Cross GCC toolchian, try to add all the pathes to 'include', then try to build (I'm on this path, but it seems Eclipse Juno needs me to find the path to include files myself, which is a lot to add manually T_T)
Create a new makefile project, import the code gradually as I go, I'm not super familiar with the code yet...
Some other ways...
Any suggestions please?
Also, in my case, which of the 3 options mentioned in http://www.vtk.org/Wiki/CMake:Eclipse_UNIX_Tutorial would be a good choice?
Pardon me if this is a "noob" question, I'm overextending myself a bit with this.
I'm trying to compile a library written in C for use in an iPhone app I'm developing. I can't seem to figure out how to do this, and I've been searching and trying things for hours.
I've tried using an External Build System project, and selecting the folder where the makefile.in.am.mingw are.
I've tried creating a Static Library project and adding the header\source files to the project. Which looked good until I tried to compile and got 260k+ errors.
When I 'cd' to the directory with the makefiles and type 'make' I get:
No targets specified and no makefile found. Stop.
I have no idea how makefiles work, I just want to use the library!
Is there a simple way to do this? If someone could at least point me in the right direction, I would be quite appreciative.
The makefiles you have are for GNU automake (under MINGW by the look of it). Even if you get them working (automake can be tricky, but it is included in Mac OS X's development thankfully), it probably won't help you much in building an iPhone library.
I did this with an existing C library by creating a new framework target in Xcode with the right include settings, etc gleaned from looking at the makefiles. That created a .framework bundle with headers and an iPhone .a library ready to be used by an iPhone project. You could also just import the C source into the iPhone project, and have it compiled in that way which would probably be quicker.