I am trying to use MIDL compiler with cmake and that's what I came to.
In the similar questions people sujjest to use add_custom_command, but I suppose it is outdated since simply adding the IDL file to the list of files does the trick.
However there are problem with this approach:
Output files are not added to the list of files, so the compiler doesn't compile them.
1.1. Adding files manually doesn't work because cmake can't find them (since they don't exist)
Output files are created in the intermediate directory, where cmake doesn't really gives access to.
It changes default names of the output files in the project settings (e.g. %(Filename).h instead of %(Filename)_i.h for header files).
So my question is did somebody encountered these issues and if so how to fix them?
Using add_custom_command is undesirable because Visual Studio doesn't treat it as a normal IDL file, so you have to setup everything manually.
Related
I am having trouble building the XLNT (https://github.com/tfussell/xlnt) library in Visual Studio 2017, and I'm confused. I downloaded the latest version of the library and the latest version of CMake. When I ran the CMake gui, it couldn't find the libstudxml files. A post said that those needed to be downloaded; so I downloaded that library (https://www.codesynthesis.com/projects/libstudxml/#download) and placed it in third-party/libstudxml.
Then I got errors that it couldn't find some .hxx files in libstudxml. I found this article, https://discourse.cmake.org/t/cmake3-20-cant-generate-xint-package/2987, that said I needed to replace libstudxml in some paths in the libstudxml.build\CMakeLists.txt file with just xml. Then it still couldn't find these three .hxx files (content.hxx, exception.hxx, and forward.hxx). I looked in the libstudxml/xml folder (they were all there but extensionless). I changed the CMakeLists.txt file to not have the .hxx extension and Cmake was able to generate.
When I went to compile it in Visual Studio (hitting Project in the Cmake GUI), I got errors that some files couldn't find the content.hxx file again and the builds failed. I'm kind of running in circles. To get cmake to generate, I had to remove the .hxx extensions, but then some files complain because they are looking for them. I tried leaving the three files witout the extensions and removing the extensions from the CMakeLists.txt file, but then some of the files were looking for the files without the extension. Leaving the files both with and without the extension was also a cluster. I understand that C++ can handle extensionless header files, but the CMake file seems to want extension, but I don't think VS is happy with them.
Additionally, while I needed to change the folder name to be xml instead of libstudxml for CMake, various include files in the source code are still looking for libstudxml; so that doesn't work.
Any thoughts?
Thanks--
Al
I experienced the same problems with the same progress and blockages. Indeed changing the extensions or locations did not solve the problem. Then I tried to find another version of the libstudxml library, the creator of xlnt might have used an other one.
So I found the following archive: https://pkg.cppget.org/1/beta/libstudxml/
and placed the files in \xlnt-master\third-party\libstudxml , without modifying the names of the CMake path. This time I was able to compile the library (mingw32-make, I'm not using VS17 in my case).
Situation
I learned a lot over the last year, but this is something I just could not wrap my head around. Project is C++. CMake 1.15.2. Visual Studio 2015.
I converted a whole Solution *.sln file with cmake-converter and wrote FindXXX.cmake Modules for all external *.libs defined in the *.vcxproj files.
Everytime I encountered an error: unresolved external I added the corresponding Target Sometarget::somecomponent to the target_link_libraries(ConsumingTarget ... ) call.
Now I have a build that works and produces no errors. Some executables say something along the lines of:
"Execution of code cannot be continued because somecomponent.dll is not found..."
I have
An original .sln file that produces executables only requiring .lib files
A CMake generated .sln file that produces executables requiring .dll files
Working FindXXX.cmake files which add_library(XXX::yyy UNKNOWN IMPORTED)
They find the headers and the .lib files (.dll files are not existing/intended/needed in the original VS .sln)
They create the corresponding Targets for all .lib files
Consuming Targets which target_link_libraries(ConsumingTarget PRIVATE XXX::yyy)
"A working build"
An error "before starting the main function".
What I have tried
I have tried defining an OBJECT Library and adding this to the sources of ConsumingTarget and removing Sometarget::somecomponent from the target_link_libraries call. CMake Doc on Object Libraries
I have tried reading and understanding the difference between module and library. Even the CMake documentation on imported Libraries couldn't help me understand my problem.
I have tried reading and understanding the difference between linking a static and shared library.
My Assumptions
Adding the imported library is done wrong by me.
Reason: DependenciesGui.exe shows different dependencies for the cmake-generated-executable and the original-sln-executable but the linker calls (shown in VisualStudio 2015) seem to be the same.
Whole Program Optimization in the CMake File does not work the same way it does in the original .sln file although the Flags are activated at all levels described in this answer.
Reason: compiling with the original file I noticed warning C4505: 'foobar': unreferenced local function has been removed - I don't seem to get those warnings with the cmake-generated build.
subassumption: Functions which won't be called are optimized away, thus removing the necessity for the .dll file.
I expect/hope for
ConsumingTarget.exe to run without asking for somecomponent.dll
another explanation on imported targets and how to link libraries where .dlls should not be necessary.
an explanation on how to analyze/compare the two binaries regarding their symbols(?) and map the seen information to CMake commands. (I am using DependenciesGui.exe to look for dependencies in the .exe file)
Possible reason for failure
One executable had no /DELAYLOAD... directive after conversion with cmake-converter. Opened Issue. Question Title still holds.
Edits:
1: Added possible reason for failure
I'm building some custom Qt components as a static library, but I can't get past the compilation phase.
My project is structured as follows:
Root:
- .h and . cpp files of the custom Qt components
- GeneratedFiles/Debug/ <-- here the MOC compiler puts the generated moc_*.cpp files ("Debug" is automatically deducted from the build configuration, so it's Release for release builds)
That's a pretty standard folder setup, but for whatever reason the compiler can't find only the moc files. Anything that is in the root folder builds just fine, but the moc files are not found. Please note, the moc_ files are generated just fine and exist where they're supposed to be, with the correct content. The problem seems to be in the evaluation of the path GeneratedFiles\Debug\moc_whatever.cpp.
Interestingly enough, if I move a moc file (say, moc_example.cpp) in the root folder and manually adapt the call to CL.exe to compile moc_example.cpp instead of GeneratedFiles\Debug\moc_example.cpp, the file gets built.
I'm using VS 2017 version 15.7.1, CL is version 19.00.24215.1 for x64 and I'll update the question with any other detail might be useful, just add ask in a comment.
So... Why is the compiler telling me those files do not exist?
I finally solved this rebuilding the directory structure in a new directory. Apparently, using WSL's git to check out repositories under Windows breaks something in the filesystem in a way that is invisible from Explorer or Ubuntu's command line, but that breaks the compiler (and Visual Studio's intellisense).
Checking out the repository with Git for Windows seems to avoid causing the same problem.
I am converting a C++ project created using Visual Studio 2005 to CMake and have stumbled upon a bit of a problem with resource files that are included in the project.
The project includes a .rc file, a bunch of .ico files and a .rc2 file.
The regular .rc file works fine in the generated project and uses the resource compiler. The .ico and .rc2 files however are causing problems when they are just being included, because in the generated project Visual Studio attempts to compile them using the C/C++ compiler.
I assume that these files are included by the .rc file, so it would probably work to just not include them in the CMakeLists.txt file, but since it is obviously possible to list them in the project (they are visible in the original project) I would like to do so, so that the user of the generated project can see that these files are being used.
What is the correct way to handle these extra VS resource files in CMake?
Try to set_source_files_properties(your.ico your.rc2 PROPERTIES LANGUAGE RC).
By default it shouldn't do anything with those files. The source file property LANGUAGE should be empty and thus the action for the file should be checked by the file type. Which shouldn't be anything since it's not something it should compile.
Check your CMakeLists.txt that is doesn't contain a set_source_files_properties command that would mess with that property.
If you want to do something with the files, here are two ways to do things:
With add_custom_target you can add them and run custom commands for them when you build the project. Granted that the files have changed.
With configure_file you can easily copy them to a build directory if needed. With the COPYONLY flag.
I have code that must be shared between two executables in the same project (one build command will build them both). This code contains #ifdef preprocessor statements which change how it works in each project (a command-line macro definition is used as a switch).
The source is abstract in the sense that some headers are missing. For example, the shared file Application.cpp might include a file called gui/MainWindow.h which doesn't exist int he shared directory but does exist in the executable source directory. Or it may include a file called gui/Local.h that does exist in the shared directory.
Essentially I need the gui path to be a combination of two locations.
On unix I've done this before simply by setting up a series of file links, but this project now has windows as a target (Visual Studio). Also, I am aware of how to do this using a shared directory structure and setting compiler include switches, but I'm hoping there is a simpler way.
Any ideas?
I use CMake for the build generation and GCC and Visual Studio as compilers.
I've already looked at defining a directory for the preprocessor, but the #include directive unfortunately cannot combine several tokens to create a filename. A single name works, and this might be an option to have cmake spit out macros for all the shared file names.
I really think the simplest solution is to use include paths - have different paths for the different projects. Look at property sheets to share settings between projects and greatly simplify the management.
If you are using file links in unix, you could do the same in Windows with symbolic links.