I like qtcreator. I need to work on a GNU-make-based project. It's a bit weird C++ project where most build rules look like
mos build directory-name
Can I use qtcreator with only the filesystem representation of the project? Or do I need to write down a very simple CMakeLists.txt? Can you give me an example of one that simply recursively lists all subdirectories?
For anyone deciding to go the recursive way, this question helps a lot.
Related
I have this project that I have done for experimentation with Qt and shared libraries. This is basically a couple of Qt Widgets from the tutorials for Qt and what I think is the right CMakeLists configuration so a MylibConfig.cmake is automatically generated from a MylibConfig.cmake.in to share the library. The problem is that I don't want the end user to add the dependencies of my library to its own CMakeLists.txt. This is, in my case, the library depends on Qt4, but I want that the end user to not have to do find_package(Qt 4 REQUIRED). Imagine that I want to provide an enclosed functionality to someone that does not need or want to know about what my library is built on. Is there a way in the automatic generation of the MylibConfig.cmake that it automatically finds all necessary packages or is the only option to add the fin package manually in the MylibConfig.cmake.in?
Thank you very much.
In fact, both mentioned projects do find of dependencies from their *Config.cmake files. And nowadays that is the only option -- CMake can't help you to do it "automatically".
So, some way or another, your config module should do the same.
The easy way is to add find_dependency() calls (cuz you know exactly what other packages, your project is based on).
A little bit harder is to do it "automatically" (writing your own helper function) -- for example by inspecting properties of your target(s), "searching" where all that libraries come from and finally generating find_dependency() calls anyway.
I have to build a slightly patched version of GCC for a project and than compile the rest of the project with it. I am wondering what is the best way to do this. I am currently using ExternalProject_Add to build the compiler as a dependency for other binaries, but I don't know how to change the compiler for a part of the project.
Your best bet is probably to structure things as a superbuild. A top level project would have two subprojects built using ExternalProject_Add. The compiler would be the first subproject and the second would be your actual project which could then make use of the compiler by making your real subproject depend on the compiler subproject.
A second alternative is discussed here where your actual project remains as the top level project, but the compiler is built as a sub-build invoked via external_process(). I've used this approach for real world situations and while it does work, I'd personally still go with the superbuild approach if I had the choice since it's a bit cleaner and perhaps better understood by other developers.
Lastly, consider whether something like hunter might be able to take care of building your compiler for you. Depending on what/how you need to patch GCC, this may or may not be the most attractive approach.
I would use two CMake projects, one building your compiler, the other building your actual project with your built compiler. The CMake compiler is such an essential part of CMake, that changing is asking for trouble.
If you prefer having everything in one project, you can call your actual project with add_custom_command and call for a sub-folder. As a user this would be more surprising, but could lead to a better integration.
Is there any way to get the number of classes in a project or the complete workspace in Xcode?
A simple way to get a rough idea for a project is by checking the Compile Sources section of the project's Build Phases. The compile sources will list all source files (.m, .swift) and doesn't include any headers.
Assuming roughly one class per source file, this will give you a ballpark idea of how many classes there are in your project at a glance. Note that this doesn't include any embedded projects or frameworks.
You could use cloc which can also be installed via Homebrew: brew install cloc.
Cloc is an open source command line tool for counting lines of code, but it also provides the count of files grouped by file type. The simplest form is cloc <path-to-your-project-dir> but the output can be configured by parameters.
A more complex solution (IMHO too complex) is, using Sonarqube with an Objective C plugin. Sonarqube has a nice interface and many functions, but just for counting classes, it's way to much.
This question is about the project command and, by extension, what the concept of a project means in cmake. I genuinely don't understand what a project is, and how it differs from a target (which I do understand, I think).
I had a look at the cmake documentation for the project command, and it says that the project command does this:
Set a name, version, and enable languages for the entire project.
It should go without saying that using the word project to define project is less than helpful.
Nowhere on the page does it seem to explain what a project actually is (it goes through some of the things the command does, but doesn't say whether that list is exclusive or not). The cmake.org examples take us through a basic build setup, and while it uses the project keyword it also doesn't explain what it does or means, at least not as far as I can tell.
What is a project? And what does the project command do?
A project logically groups a number of targets (that is, libraries, executables and custom build steps) into a self-contained collection that can be built on its own.
In practice that means, if you have a project command in a CMakeLists.txt, you should be able to run CMake from that file and the generator should produce something that is buildable. In most codebases, you will only have a single project per build.
Note however that you may nest multiple projects. A top-level project may include a subdirectory which is in turn another self-contained project. In this case, the project command introduces additional scoping for certain values. For example, the PROJECT_BINARY_DIR variable will always point to the root binary directory of the current project. Compare this with CMAKE_BINARY_DIR, which always points to the binary directory of the top-level project. Also note that certain generators may generate additional files for projects. For example, the Visual Studio generators will create a .sln solution file for each subproject.
Use sub-projects if your codebase is very complex and you need users to be able to build certain components in isolation. This gives you a very powerful mechanism for structuring the build system. Due to the increased coding and maintenance overhead required to make the several sub-projects truly self-contained, I would advise to only go down that road if you have a real use case for it. Splitting the codebase into different targets should always be the preferred mechanism for structuring the build, while sub-projects should be reserved for those rare cases where you really need to make a subset of targets self-contained.
I am working on a project and I have a plan to separate certain sections out into separate dlls/ndlls in the final program. The main reason I want to do this is to support plugins and add ons, so more functionality can be added if needed, but the core app can still be used if that's the only requirement.
I have done something similar in C# (abet through an IDE so I never had to write any linker/compiling commands) so I know the general process but I can't seem to find a way to write HX code and then have it compile into a ndll.
I found this http://old.haxe.org/doc/cpp/ffi?lang=en which shows how to compile cpp code into a ndll using hxcpp and g++. I would think there should be a way I can use LIME or HXCPP to create a build file that will allow me to do it in one step instead of having to make a "fake" main function to compile the HX to CPP or CS.
If anyone knows of a project that does this and has a build.hxml or build.xml file that describes this or a tutorial or guide that takes about this, I would love it see it.
Try this:
lime create extension TestExt
lime rebuild TestExt windows
Replace "windows" with "mac" or "linux" as appropriate. Assuming it works, the ndll will show up in a subfolder of TestExt/ndll/.
As for tutorials, I wrote this one. It's targeted at OpenFL programmers, but the "Writing code for iOS" section covers what you'll need to know. (You can also just model your code on the template.)
In case it helps, I've made a tool to generate some of the boilerplate code that Lime requires.