Linking a CMakeProject and a makefile project - c++

I’ve got a project that needs to use the Nash Equilibrium solving capabilities of Gambit-Project
This is a performance critical application, so I have to somehow link my codebase with Gambit.
My actual use case sounds simple to me. There is one executable in the folder that has all the top level functions that I need.
The problem is that I am new to Cmake, and C++ in general. Additionally, Gambit is a very mature project that does not use Cmake; Instead, it uses its own make file which is quite difficult to parse.
My project is here: https://github.com/baskuit/surskit/blob/master/CMakeLists.txt
The CMakeLists.txt is very rudimentary (and half commented out this commit)
And Gambit project is here: https://github.com/gambitproject/gambit
with the required source file here: https://github.com/gambitproject/gambit/tree/master/src/tools/enummixed
I’m hoping that there is someway to link these two projects without delving into that heinous makefile.

Related

First steps to adding a static library to c++/ROS (CMake)

I'm trying to add a static library to my C++/ROS project and having trouble wondering where to start. I have the project currently working with a CMake file to build it and have downloaded (and can build) an external static library that I want to use in the project.
I am very new to CMake and C++ in general and am working on a project that I haven't created myself. I've read a lot of tutorials on how to add libraries but I'm stuck at knowing where to start as I know there are many different steps needed. I was looking at find_library(), add_library() and ExternalProject_Add() but I don't really understand the difference and the documentation doesn't make it much clearer. As it stands the CMake file has very little in it so I was wondering what exactly I need to add and what commands are best just to be able to use this library in my project. Specifically, I guess what set of commands would I add to a pretty empty CMake file for it to work given I have the lib.a file. Sorry for the vagueness but any help would be appreciated.

How to convert a cmake project into a Visual Studio equivalent?

The situation is the following: I have the source code of one programm (lets call it programA) (written in C and C++), as well as the CMakeLists.txt and CTestConfig.cmake files. I already installed programA using CMake's graphical user interface and, as it is obvious, it worked. It created the .exe file (I'm working on Windows 7 OS).
The problem is that, right now, I've been asked to edit the program (and so, I must be able to edit the code and degugging it as changes are made). I also need to compile it but not in .exe anymore but in .dll so I can add it to a website we have.
I've read in forums that CMake can compile programA into a .dll if I need to, but as I would need to make some changes I consider that CMake debugging is not as useful and easy as using entirely VS. From the little I know from CMake language, the CMakeLists.txt is mainly used to check the OS of the user as well as adding some libraries in case they are not found.
I have to admit I have no idea in programming CMake directives, as I have been working with ASP.NET, C, C++ and C# mostly. Then, my idea is to try to work only in visual studio 2010 instead of using cmake as well, so once I have the program 'adapted' to VS and can be compiled just using VS, I'm ready to start my job. So the question I have is how can I perform the same task CMake did just using Visual Studio (Is there any way of implementing CMake directives in VS?), can VS compile by receiving as an argument something similar to that CMake.txt file (though it needs to be translated into another language)?
To skip the use of CMake I tried to copy the source code into a new project in VS. However as it does not use the CMake directives when compiling, it gives several errors, most of them related to the fact that some headers.h can't be found (cause they might be in a subfolder). And there are so many subfolders to add the paths to the predefined directories of search that it would take ages.
I'm sorry I can't be more precise in my explanation. I'm good at programming little projects on my own, but it's the first time I have to work on other's programm. Please don't hesitate to ask if anything was not properly understood
I would appreciate a lot any suggestion / advice /guidance you can give.
To make a dll, use add_library command and the SHARED keyword
add_library(mylib SHARED ${files})
this is easy with CMake, don't go back in visual that will be harder at the end
The Good News
Fortunately, cmake can generate VS Projects automaticaly for you (this tutorial s specific for OpenTissue, but Steps 1 to 3 should be the same for you).
The [not so] Bad News
Depending on the complexity of the project, VS Projects automaticaly generated by cmake can get pretty nasty, to the point of illegibility. It will, for example, hard link any library dependencies using the specific paths of your machine, so the project will most certainly not be portable across setups. In any case, that's the intended bahavior, because the primary idea of supporting this generator is simply making it work, thus allowing users to easily compile projects using MSVC, so there's not much you can do here. Nonetheless, it should work in your machine and will certainly be a great starting point for you, just create a project yourself from scratch copying the relevant parts out of the automatic generated version.

Testing C++ code: Using test libraries

I've been studying C++ for a while, but this is the first time I'm into a C++ project (a pet configuration parser library). I'm using the Google C++ Testing Framework to test this. But I don't know if I'm doing it right.
Currently, I've ripped off some parts of this Google test library and put it into my projects Test/googletest directory. It works OK, but I wonder if this is how I'm supposed to do this. I'm including the source code of the testing framework in my project and it will be released with my code. This makes me feel uncomfortable.
I wandered through some C++ projects on GitHub, trying to see how other people deal with this. Some have custom framework-lets, and most solve the whole problem with not testing the code at all.
I wonder if I'm taking this right, or otherwise how can I adopt a testing method that will both keep the framework out of my source tree and let me release my code with tests buildable and executable by the user?
Concerning your build, you're doing it right. The gtest readme explicitly states that building gtest (you can pack a libgtest.a from the two object files) along with your project is the prefered way to do it.
Concerning the distribution:
Ideally, you could have your build tool (make, CMake, etc) check out / fetch the required gtest version from its own repository. But I don't think there is much harm if you add an "external" folder to your project and include stuff like gtest in your own repository.

How to generate CMakeLists.txt?

I need some pointers/advice on how to automatically generate CMakeLists.txt files for CMake. Does anyone know of any existing generators? I've checked the ones listed in the CMake Wiki but unfortunately they are not suitable for me.
I already have a basic Python script which traverses my project's directory structure and generates the required files but it's really "dumb" right now. I would like to augment it to take into account for example the different platforms I'm building for, the compiler\cross-compiler I'm using or different versions of the libraries dependencies I might have. I don't have much\expert experience with CMake and an example I could base my work or an already working generator could be of great help.
I am of the opinion that you need not use an automated script for generating CMakeLists.Txt as it is a very simple task to write one, after you have understood the basic procedure. Yeah I do agree that understanding the procedure to write one as given in CMake Wiki is also difficult as it is too much detailed.
A very basic example showing how to write CMakeLists.txt is shown here, which I think will be of use to everyone, even someone who is going to write CMakeLists.txt for the first time.
Well i dont have much of an experience in Cmake either, but to perform a cross platform make a lot of files need to be written and modified including the CMakeLists.txt file, i suggest that you use this new tool called the ProjectGenerator Tool, its pretty cool, it does all the extra work needed and makes it easy to generate such files for 3'rd party sources with little effort.
Just read the README carefully before using it.
Link:
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=54842
I think that you are doing this upside down.
When using CMake, you are supposed to write the CMakeLists.txt yourself. Typically, you don't need to handle different compilers as CMake has knowledge about them. However, if you must, you can add code in the CMakeFiles to do different things depending on the tool you are using.
CLion is an Integrated development environment that is fully based on CMake project file.
It is able to generate itself the CMakeLists.txt file when using the import project from source
However this is quite probable that you have to edit this file manually as your project grows and for adding external dependency.
I'm maintaining a C++ software environment that has more than 1000 modules (shared, static libraries, programs) and uses more than 20 third parties (boost, openCV, Qt, Qwt...). This software environment hosts many programs (~50), each one picking up some libraries, programs and third parties. I use CMake to generate the makefiles and that's really great.
However, if you write your CMakeLists.txt as it is recommended to do (declare the module as being a library/program, importing source files, adding dependencies...). I agree with celavek: maintaining those CMakeLists.txt files is a real pain:
When you add a new file to a module, you need to update its CMakeLists.txt
When you upgrade a third party, you need to update the CMakeLists.txt of all modules using it
When you add a new dependency (library A now needs library B), you may need to update the CMakeLists.txt of all programs using A
When you want a new global settings to be changed (compiler setting, predefined variable, C++ standard used), you need to update all your CMakeLists.txt
Then, I see two strategies to adress those issues and likely the one mentioned by OP.
1- Have CMakeLists.txt be well written and be smart enough not to have a frozen behaviourto update themselves on the fly. That's what we have in our software environment. Each module has a standardized file organization (sources are in src folder, includes are in inc folder...) and have simple text files to specify their dependencies (with keywords we defined, like QT to say the module needs to link with Qt). Then, our CMakeLists.txt is a two-line file and simply calls a cmake macro we wrote to automatically setup the module. As a MCVE that would be:
CMakeLists.txt:
include( utl.cmake )
add_module( "mylib", lib )
utl.cmake:
macro( add_module name what )
file(GLOB_RECURSE source_files "${CMAKE_CURRENT_SOURCE_DIR}/src/*.cpp")
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/inc)
if ( what STREQUEL "lib" )
add_library( ${name} SHARED ${source_files} )
elseif ( what STREQUEL "prg" )
add_executable( ${name} ${source_files} )
endif()
# TODO: Parse the simple texts files to add target_link_libraries accordingly
endmacro()
Then, for all situations exposed above, you simply need to update utl.cmake, not the thousand of CMakeLists.txt you have...
Honestly, we are very happy with this approach, the system becomes very easy to maintain and we can easily add new dependencies, upgrade third parties, change some build/dependency strategies...
However, there remains a lot of CMake scripts to be written. And CMake script language sucks...the tool's very powerful, right, but the script's variable scope, the cache, the painful and not so well documented syntax (just to check if a list is empty you must ask for it's size and store this in a variable!), the fact it's not object oriented...make it a real pain to maintain.
So, I'm now convinced the real good approach may be to:
2- completly generate the CMakeLists.txt from a more powerful language like Python. The Python script would do things similar to what our utl.cmake does, instead it would generate a CMakeLists.txt ready to be passed CMake tool (with a format as proposed in HelloWorld, no variable, no function....it would only call standard CMake function).
I doubt such generic tool exists, because it's hard to produce the CMakeLists.txt files that will make everyone happy, you'll have to write it yourself. Note that gen-cmake does that (generates a CMakeLists.txt), but in a very primitive way and it apparently only supports Linux, but it may be a good start point.
This is likely to be the v2 of our software environment...one day.
Note : Additionally, if you want to support both qmake and cmake for instance, a well written Python script could generate both CMakeLists and pro files on demand!
Not sure whether this is a problem original poster faced, but as I see plenty of „just write CMakefile.txt” answers above, let me shortly explain why generating CMakefiles may make sense:
a) I have another build system I am fairly happy with
(and which covers large multiplatform build of big collection
of interconnected shared and static libraries, programs, scripting
language extensions, and tools, with various internal and external
dependencies, quirks and variants)
b) Even if I were to replace it, I would not consider cmake.
I took a look at CMakefiles and I am not happy with the syntax
and not happy with the semantics.
c) CLion uses CMakefiles, and Cmakefiles only (and seems somewhat interesting)
So, to give CLion a chance (I love PyCharm, so it's tempting), but to keep using my build system, I would gladly use some tool which would let me
implement
make generate_cmake
and have all necessary CMakefiles generated on the fly according to the current
info extracted from my build system. I can gladly feed the tool/script with information which sources and headers my app consists of, which libraries and programs it is expected to build, which -I, -L, -D, etc are expected to be set for which component, etc etc.
Well, of course I would be much happier if JetBrains would allow to provide some direct protocol of feeding the IDE with the information it needs
(say, allowed me to provide my own command to compile, to run, and to
emit whatever metadata they really need - I suppose they mainly need incdirs and defines to implement on the fly code analysis, and libpaths to setup LD_LIBRARY_PATH for the debugger), without referring to cmake. CMakefiles as protocol are somewhat complicated.
Maybe this could be helpful:
https://conan.io/
The author has given some speeches about cmake and how to create modular projects using cmake into CPPCon. As far as I know, this tool require cmake, so that I suppose that generate it when you integrate new packages, or create new packages. Recently I read something about how to write a higher level description of the C/C++ project using a YAML file, but not sure if it is part of conan or not (what I read was from the author of conan). I have never used, and it is something pending for me, so that, please if you use it and fit your needs, comment your opinions about it and how it fit your scenario.
I was looking for such a generator but at the end I decided to write my own (partly because I wanted to understand how CMake works):
https://github.com/Aenteas/cmake-generator
It has a couple of additional features such as creating python wrappers (SWIG).
Writing a generator that suits everyone is impossible but I hope it will give you an idea in case you want to make your customized version.

Import existing C++ project into Xcode IDE

I am trying to open an existing C++ open-source library in Xcode to publish it with my own modification/additions. The library is Tesseract-OCR, which does not include a .xcodeproj file.
Since Xcode can function as an IDE, is it possible to open a bunch of files as a single project in Xcode? Is there an easy way to produce an Xcode project?
There are several ways you could do it, depending on the level of IDE integration you want. There's no direct way of importing a Makefile-based project into Xcode. You can create a project that builds via the Makefile, but you wouldn't get many of the benefits of using an IDE, since the editor features such as word completion rely on Xcode being able to parse the files in the project. You will be able to use the debugger though. To do this, create a new project and add a custom target with a script build phase that just calls down to Makefile.
If however the project you're building compiles very easily, ie without requiring a lot of macros to be set up, include paths, etc, then it may be simple to just create an empty project and merely add all source files to it. I've used this method extensively for building boost libraries. If this is a configure && make type project then you will probably have to run the configure step first, and ensure any top level config.h files are included in the project.
If the project has a complex makefile then it is likely to be an involved task to create a useful Xcode project
I realise you asked explicitly for Xcode, but in case you were actually trying to solve the problem of "I have existing C++ code which builds and runs fine from the command line, and I'd like to code and debug it in an IDE, what should I do?" my firm recommendation would be to avoid Xcode and go for Eclipse.
The reason is that as far as I can tell, Xcode has no way of ingesting the command line build environment and effectively requires you to recreate the make process inside Xcode from scratch. Fine for tiny projects, but anything with more than a few source files and it quickly becomes painful. Whereas in Eclipse everything is built around Makefiles. So in my case I got to the "step through code with working code completion" in Eclipse a lot quicker vs. never in Xcode. This of course could be because I'm an Xcode noob, but my 2c.
To create an Xcode project from an existing cmake project, you can run cmake -G Xcode. It produces some folders and files apart from the project file, so it might be better to create a folder for it first. For example:
mkdir -p build/xcode
cd build/xcode
cmake -G Xcode ../..
Xcode is a useable IDE for library creation.
Of course a good first step is to see if the one source code will build on its own with configure scripts that are included.
If not, it becomes a question of how many libraries you need to link in.
There are resources online (or at least there used to be) for using Xcode (or perhaps it's forerunner Product builder) for porting Unix projects to Mac.
Good tutorial at: http://www.macresearch.org/tutorial-introducing-xcode-30-organizer
Another good reference is Darwin Ports.
As for doing this on your own. You can build c++ based libraries in XCode. People do that every day. You can even use one of the Xcode templates to get you started.
However, library dev requires more experience with Xcode then say a simple Cocoa "Hello World" app.
The remaining questions will be assuring that the source code's dependencies are already built into the Mac's SDK. (Don't hold your breath for linking to MFC)
It's a general question... So it's a general answer.
In Xcode8,there is "Xcode->file->add files to...",then choose your files.If you want to add several files at a time,press "Cmd" when you are choosing.