I'm developing a large project using Qt 4.6, CMake 2.8 and Visual Studio 2008 for the Windows platform.
As far the build system goes, it's all standard stuff: I'm using CMake's QT4_WRAP_CPP macro to generate moc files from header files, which are then linked into the final executable in the add_executable command. Everything is working as expected.
The only restriction with this setup is that I can't define widgets or helper using Q_OBJECT in .cpp files. This would be very convenient for small, context-specific helpers classes that should appear right next to where they're used.
I tried to pass the whole list of source files (both .h and .cpp) to QT4_WRAP_CPP, instead of just the header files, but that doesn't work (linking fails because some moc-related symbols are undefined).
I think the problem is that, for a given pair of files foo.h and foo.cpp, the QT4_WRAP_CPP macro will generate the same moc file (moc_foo.cxx) in the same directory, and obviously that means the first file will be overwritten by the second one, and as a result symbols will be missing at link-time.
Is there a way to fix or work around that problem? For instance, I tried to add a specific rule for foo.cpp of the form
QT4_GENERATE_MOC(directory/foo.cpp directory/foo.moc)
and then add
#include "foo.moc"
at the end of foo.cpp. I think this ought to work, but alas Visual Studio only allows one build rule per file, and .cpp files already have a build rule (compilation to object file), so this approach doesn't work, at least with Visual Studio.
Another idea that I had was to create a new macro, say QT4_WRAP_CPP_WITH_PREFIX, based on QT4_WRAP_CPP (which is defined in share/cmake-2.8/Modules/Qt4Macros.cmake), that would take an additional prefix argument and would add this prefix to the generated moc files. That way, I would call QT4_WRAP_CPP_WITH_PREFIX twice, once for .h files and once for .cpp files, with different prefixes. What I just dislike about this approach is that I'd be messing with the internals of CMake's Qt support, instead of using the public API.
Any better idea?
Recent versions of CMake have "automoc" which worked like a charm for me:
http://blogs.kde.org/2011/11/01/cool-new-stuff-cmake-286-automoc
Simply add in the CMakeLists.txt:
set(CMAKE_AUTOMOC TRUE)
and then in the cpp (e.g. example.cpp) file:
#include "example.moc"
(the *.moc must match the cpp file's name).
Referring to the documentation "Using the MOC" (http://doc.qt.nokia.com/4.1/moc.html), you'd only need to import "foo.moc" at the end of your implementation file. As you can not tweak the build rules correspondingly, try to export a .pro file and apply the build rule as suggested by the nokia document.
Related
Visual Studio 2019. Windows Runtime Component C++/WinRT project.
How do I follow and implement the recommendation: "We recommend that you declare each runtime class in its own Interface Definition Language (IDL) (.idl) file, in order to optimize build performance when you edit an IDL file, and for logical correspondence of an IDL file to its generated source code files. Visual Studio merges all of the resulting .winmd files into a single file with the same name as the root namespace. That final .winmd file will be the one that the consumers of your component will reference."
https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-apis
Within the same project I can add a second (third and so on) .IDL file using Project->Add New Item->Midl File (.idl). This seems to work ok?! I then manually add associated .h and .cpp files for each .IDL file. Build to generate stub files then manually copy and "fill in" these files before a final build which is successful. In this way I have a single IDL file per runtime class with its associated headers and implementation files including any other files (c++ .h and .cpp files) needed for the implementation. As I need to add functionality to the interface I just edit the IDL file, rebuild and add functionality to the header and implementation C++ files.
Is this what was recommended?!?
When I add the .IDL file and then manually add an associated .h and .cpp they do not appear "under" the .IDL file as the original ones did when I created the new project. Is this just a visual nicety of Solution Explorer OR is this indicating that I have something wrong?!?
I plan to have multiple "C++/WinRT WRC" projects (one for each namespace, each consisting of multiple runtimeclass interfaces with separate .IDL/.h/.cpp files as described above. Then I reference all of the projects (project to project) in my single C#/UWP App.
I am actually trying to implement a user interface to allow me to utilise a large code base of math/engineering C++ classes that implement a very specific & proprietary type of electronic circuit simulation already existing and programmed in C++ and compiled as a console app. The user data in and out is relatively small compared to the processing that takes place to generate the output.
It looks like you are handling the idl files correctly and that behavior is the same as I experienced when just adding a new Midl file directly.
If you like the look of having the .h and .cpp files "under" the .idl file in the tree you can try adding a new View Model instead of a new Midl file. This will create the .idl/.h/.cpp files all with the same name and place the .h and .cpp files visually under the Midl file. The idl template you get this way is for a basic runtime class.
When creating a new Windows Runtime Component, the .idl and the .h are usually grouped under the .cpp, not the .idl, but whatever your preference. There isn't a template to add a Runtime Class, which is pretty dumb. One fix for this could be as follows:
This is not a perfect solution, but is the easiest. Create a new Windows Runtime Component. Open Project>Export Template. Select Export Item. Select the Runtime Class under the new component. Export with Automatic Import option checked. Save your project and exit VS. Open your project. You can now add a fully templated Windows Runtime Class by simply adding item>Runtime Class. However, there will still be no dependencies (there may be a tool for custom nesting, but not in community as far as I can see). To fix this, after adding the files, save the project. Edit the project file (use notepad++ or even unload project, edit) and add the property <DependentUpon>Runtime Class.idl</DependentUpon> between your .cpp and .h file delimiters. Save the project file and reload. Probably want to do this in batches.
The alternative is to write a .vsix to either add the files and edit the project file, or have a right click command that runs on a .cpp and edits the project file, adding the DependentUpon directive. I can't find a 2022 functional .vsix for this. I will post one if I make one.
I tried to add my USART library to my project but I am still failing to properly add it so it will be recognized.
I created an USART.c and USART.h file, which I want to add. This is what I tried:
1) Right Click on the Solution / Properties / Toolchain / Directories
2) Adding the Path where I got these two files
When I try to build the project, it did not work. I get the message undefined reference to 'initUSART'.
How do I add my own libraries to projects then?
The screenshot in your question shows that you arranged for the compiler to find the header files for your library. But you also need to use the compiler to compile your library functions (e.g. initUSART) and create a static library file (with a lib prefix and a .a extension). You would need a separate Atmel Studio project for that, or learn how to use the AVR GCC toolchain outside of the IDE to compile libraries. Then you need to put that file in a directory that is in the linker's search path for libraries, and then you need to pass the appropriate -l argument to the linker. For example, if your library is called libuart.a, you need to pass -luart to the linker. The Project Properties for an Atmel Studio project has the relevant settings you need to configure.
GCC has a standard way to compile, create, and link to static libraries, which I outlined above. You can learn about that from any tutorial on GCC static libraries. You then would need to apply that knowledge to the AVR GCC toolchain, and find the appopriate options inside Atmel Studio that you need to set.
Aside: Atmel Studio does not make it easy to use libraries at all. The Arduino IDE does a much better job because you just put the source files for the library in the right place and it compiles them for you. There are a huge number of Arduino libraries too; you wouldn't have to write your own UART driver if you could use the Arduino platform.
The simple alternative: If you don't know much about compiling and linking to C libraries and configuring your IDE, you would have a much easier time just copying the library files into your project, adding them as source files, and letting Atmel Studio compile them just like any other source file in your project.
Another simple way of adding folders to your project is to copy/paste the folder into your project and then open Atmel Studio.
On the right side (where is by default Solution Explorer) you'll see all your files except the ones that you just added. Now press the Show all files and search for you folder which should appear grayed out. Right click on it and Include in project. That should be all!
This image should help
I got another solution that might help . i found Include Directories in this path for MegaAvr(8bit) :
C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.6.364\include
Just Puts All your Library in one Folder And Copy All of It in this path , then include it like another library . For example I created a folder named "ali" in that path , then i copied all my libraries in this folder (like alcd.h , usart.h) and then included in my programes with this :
#include <ali/usart.h>
and done ! just remember to backup your folder before Windows Installation (Drive Format) . Also you can find your libraries (.h and .c) in Solution Explorer -> Dependencies after Code Compilation .
GoodLuck ...
inside Folder
including xio.h in folder ali
xio.h in dependencies after compilation
my folder in specified path
So, I understand that CLion currently only fully supports CMake projects. I don't care if I can't compile or run anything with CLion, as I don't currently do that with Eclipse anyway. I am just looking for editor support, with nice click-to-follow, autocomplete, etc.
What I am wondering is whether or not indexing can still work for non-CMake projects. I can create my project just fine, and indexing completes just fine, but after that is done it can't find my include files. It creates a default CMakeLists.txt file, in which the appropriate sources and include_directories have been added. It doesn't seem to make a difference though, as after indexing completes I still can't click-to-follow #include lines, and any references to things in other files don't work correctly.
Is there something else I can do to make indexing work so I can use CLion as an editor, or is this a pipe dream until Makefile support is someday added?
After some research, I found out your best chances are:
Once it's created, edit CMakeLists.txt (for example, see How to
find libraries). One example:
set(Library "../Library")
include_directories(${Library})
set(SOURCES main.cpp)
add_executable(project_name ${SOURCES})
Note ../ goes to the up folder and in the main.cpp you can use #include "header_to_add.h" (header_to_add.h must be in ../Library folder.
Edit the source code of you .cpp, .h or whatever to add the full path of the library you want to #include taking into account the scope starts in the directory where the file is.
For example: #include "../Library/header_to_add.h" (note the "../" goes one level up from the current folder".
(Maybe not possible or hard) Modify the makefile to prepare CMake to get the necessary inputs (for example, see this).
I recommend the first one mainly because it maintains the structure outside the source files.
Edit: Also it's possible to prepare CMake to use makefile (Source).
I am just approaching C++ development (from a C# background), and i am wondering what is the difference between Library Directories in C++ project settings (in Visual Studio):
and the Linker "Inputs" where i can also supply libraries:
Is there any fundamental difference between these?
This setting got fumbled a bit in VS2010, it was much clearer in previous versions. Where the settings you show in your screenshot were present in Tools + Options. Which shows the core intent, they contain directories that are determined by the setup for Visual Studio and its components. The locations of the CRT, MFC, ATL and SDK libraries.
The Linker + Input + Additional Dependencies setting is the important one, there you say exactly what .lib files the linker should link. You can specify the path of a .lib file and be done. But it is not uncommon that you only specify the name of the .lib file, then edit Additional Library Directories to tell the linker where to search for those .lib files. Which is handy if the install location for, say, Boost isn't always the same or you want to switch from one version of Boost to another.
So in summary:
Linker + Input + Additional Dependencies: add the .lib files you need to link
Linker + General + Additional Library Directories: only use if you didn't specify the path of .libs
VC++ directories: don't mess with it
Do note that the last two bullets only specify directories, not .lib files that the linker should link. The first bullet specifies actual .lib files. What is invariably confusing to starting MSVC programmers is that the linker magically knows how to find important .lib files without specifying them explicitly in the Additional Dependencies setting.
That's unfortunately the non-visual part of Visual C++. There are two distinct ways in which a project can specify .lib files that the linker should link without using the setting. The first one is the project template you selected to get the project started. It uses project property sheets, files that specify default settings for a project. You see them with View = Other Windows + Property Manager. An important one is "Core Windows Libraries", it sets the Additional Dependencies setting to link the essential Windows .lib files, the ones you always need like kernel32.lib and user32.lib. Those settings are "inherited" by your project. Otherwise giving meaning to "NoInherit" if you ever run into it.
The second important way is the #pragma comment directive. Which is used in source code, it injects a linker directive. The "lib" variety is important, that tells the linker to link a .lib file. In addition to what you explicitly specify in the linker's Additional Dependencies setting. A very good example of that one is vc/atlmfc/include/afx.h. Search for "#pragma comment". Note the macro soup that selects the proper mfc .lib file, depending on compiler specific settings. And the bunch of extra Windows .lib files an MFC needs to link.
The C++ build model is filled with a maze of twisty little passages. The IDE tries to make you fall in the pit of success but in the process hides what's important to get to the next level of understanding. It isn't different in C#, to know how to make the Reverse() extension method not consume O(n) storage requires digging in.
Most (not all) libraries come with two sets of files:
Header files are #included in the source code that's using the libraries, to provide declarations for functions, classes, constants or whatever else might be needed
Library files are binary code that contains the code of the library. These are used by the linker when it assembles the final executable
I have a COM project that contains a number of IDL files, some of which are imported into other ones. How does Visual Studio decide which ones to compile (using MIDL) first?
I want to control the order. I have a master IDL file which contains my library declaration with several imports, and I get a build error if it is not the first one compiled.
(If any of this sounds really weird... I'm new to COM/ATL, and it's really, really confusing).
You can't ask Visual Studio to build .ild files in a specific order. Instead you can #include some of .idl files into other .idl files and set the files you imported to "excluded from build". This way MIDL will not compile the imported files separately, instead it will include their contents into specific place of another file and compile as the part of that file (same effect as with C preprocesor #include).
You can make Visual Studio build things in any order you want, there are 2 ways to do this:
Put in a pre-build step in which you can get it to build the ones you wish to build first.
Put the ones you want to build first in a separate project and get it to build that project first by making your other one dependent on it.
This is what you should do if you cannot modify the idl files. If however one idl file really does depend on another and you can modify them, then do what was suggested above and get one to include the other.