I want to install a library (all .so files in my case) in my C project folder in order to make it portable.
The wanted result is a project that, when you download it, allows you to compile it without needing to install something with "apt", "dpkg", etc...
I managed to copy .so files from /usr/lib/... in my project folder and link it with -Lmylibfolder "gcc" option. (I did the same for headers with -Imyincludefolder).
But that, this is for libraries I need directly, and I think there are sub-dependencies I need to copy too. Moreover my method consist in copying files manually and this is not very "clean".
Is there a good way to do what I want?
Related
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 have a project written in C; it has up to six sub-directories with .mk files, a make directory, at least one makefile, and Android.mk files.
I have used Android Studio, ndk, and JNI to build a project which compiles and runs. Now I want to port the above project into it. I have read all the GNU make manual, and know that I can include other make files. My question is would it be better to use gradle to include the make files above, and can I even do it? I have not read the gradle manual yet. It is my understanding that it is a build environment; I am not clear on what are it's differences / similarities with make. And if I can use it to complement make or I just have to pick one and go with it. I did have to edit it to get the JNI project working. My initial goal is to just run the make files in the native project in silent i.e. have them not produce any .o files and see what they do and validate that I am including them; then I want to include all the .c files and build .o files. I know I can do this with include statements in make file and since I have an Android.mk file in my project, I think I can do it through that. But I wonder if in the long run it is better to use gradle. What should I do please?
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've got two projects in solution, library and executable.
First I build library but then when I start build another project it cleans library even when library files is in different folder and should not anyhow conflict with it.
How to say to not remove library by building my executable?
If your executable depends on your library, the library will be automatically cleaned when cleaning or regenerating the executable.
It will not be cleaned if only generating the executable (not regenerating), which will only compile modifications since the last build.
If your executable does not depend on your library, the library should not be cleaned.
If this is really the case, you can try to build the executable by right clicking on the project located in the solution explorer.
I have a project which I try to compile with Eclipse-CDT. The project depends on a library with header files and source files. How can I configure the project in Eclipse such that it will compile the needed source files from the library with the project?
With a makefile I use:
SRC+=lib_source.c
You can add linked source file.
Choose project properties and in the left panel choose c++ general.
Under it choose path and symbols.
Now in the right panel tabs choose source location and add linked source folder.
Include you need to define in "include" (under c++ build you will find settings)
Another approach is to use the operating system to add your libraries to the project. Eclipse then treats all source files (including library files) as part of the project, and therefore compiles any that need it even if they are in the libraries. This set-up allows keeping the library sources in a separate git repository from the project source code. You can record the git commit of a library to provide library version control so that improving the library in one project does not break all the others. The setup relies on the operating system's capability to link directories in a way that is entirely transparent to eclipse--in windows using the mklink command.
In windows the steps are
put your library files in a clean workspace not mixed with .git (you can have .git in the parent directory as egit sets it up)
use cmd window in administrator mode to add a link from your project directory to your library directory.
from eclipse press F5 t make sure your project matches what is on disk, then set up git to ignore your library directory.
set up your library file properties for read only access unless you are still tweaking that library.
set up your project include path to include the project sub-directory in your project.
I can't remember why I abandoned eclipse linked directories; i think it was that the includes kept breaking. The mklink approach has worked flawlessly so far.
I have a pdf tutorial of how to set this up--but I'm new to the forum and don't see how to attach a file.