My company has their own idl compiler, and I have CMake generating the files as a part of the build process. I want the .idl files to be in the visual studio project, but that means I end up with microsoft trying to compile the idl files with midl (which fails miserably).
I know my question is extremely similar to Adding data files to cmake-generated projects, but the major difference is that microsoft does have a compiler I just don't want them to use it.
-update-
Here is a code sample from the function that adds the idl file to the solution (The entirety of the code is too much, but if there are any declarations that might help in answering the question let me know):
function foo()
add_custom_command...
set(HEADERS ${HEADERS} bar.idl PARENT_SCOPE)
source_group("Source Files\\idl Files" REGULAR_EXPRESSION .*.idl)
endfunction()
Then later - after I call foo - I call add_executable(${PROJECT_NAME} ${SOURCES} ${HEADERS})
One thing I noticed is that nmake will compile how I want it to compile, but visual studio adds the call to midl that I don't want.
Any help will be greatly appreciated.
-update 2-
I can hack a way of 'fixing' the problem by adding a /? to the midl command line inside visual studio (but I can't ask every dev to do that each time they build), so if anyone knows how to add an argument to the midl command line from cmake that would help as well.
It's probably also a bit of a hack, but I think you could achieve this by marking the .idl files as HEADER_FILE_ONLY:
set_source_files_properties(${HEADERS} PROPERTIES HEADER_FILE_ONLY TRUE)
Related
I am using cmake + qt + visual studio to work on a project. Problem I am having it that I would like visual studio to create new moc objects if I modify the QT ui files. If I just do a full build everything works file, but if I just modify something on the ui file it does not "auto moc" and I have to rebuild the whole project.
The cmake file I have is pretty simple:
cmake_minimum_required(VERSION 3.2)
set(CMAKE_VERBOSE_MAKEFILE ON)
project(main)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTOUIC ON)
find_package(Qt5Widgets)
file(GLOB CPP_FILES *.cpp)
add_executable(main ${CPP_FILES})
target_link_libraries(main Qt5::Widgets)
target_compile_features(main PUBLIC cxx_nullptr)
Does anyone know a way to get this to work (having visual studio to detect ui file modifications and "auto moc" the modified ui file)?
Start by replacing your file(GLOB ...) with explicitly listing out the files you want to include if you want proper dependency handling. This will also ensure the build is creating dependencies for the set of files you are expecting it to. This answer has more details about why you probably want to do this, aside from the reasons below.
The CMake documentation for AUTOUIC includes this statement:
If a preprocessor #include directive is found which matches
ui_<basename>.h, and a <basename>.ui file exists, then uic will be
executed to generate the appropriate file.
Can you confirm that your .cpp sources have #include directives that follow this pattern? In your file(GLOB ...) you are only capturing the .cpp files and not the .h files, so if you've only got the #include directives in the headers, AUTOUIC may not pick them up properly. It's been a while since I've used this and I can't recall if AUTOUIC would still find them if you only list the .cpp files and not the headers too in your add_executable() call, but it's something for you to try. You also may be facing a similar situation with AUTOMOC if you have headers which use the Q_OBJECT and Q_GADGET macros. So just explicitly list out your .cpp and .h files you give to add_executable() and see if that addresses your problem.
I'm trying to compile an OpenGL program using Visual Studio 2013, but I get the following error:
Error 1 error LNK1104: cannot open file
'freeglutd.lib' ...
For reference, I have FreeGLUT installed and have configured VS to search the correct directories for the include files and library files. Indeed, VS recognises the GLUT include files just fine. I've also added opengl32.lib and freeglut.lib to the Additional Dependencies.
Why is VS looking for 'freeglutd.lib'? It's definitely not listed in the Additional Dependencies. I can solve the compilation error by renaming 'libglut.lib' to 'libglutd.lib' and removing the former from the dependencies, but I'm just curious why it's behaving this way.
Speaking of Additional Dependencies, is adding opengl32.lib actually necessary? I can compile my (very basic) program without it, but more than one person has said it's required, perhaps for older versions of Visual Studio?
if you check the freeglut_std.h (freeglut V3.0):
/* Link with Win32 shared freeglut lib */
# if FREEGLUT_LIB_PRAGMAS
# ifdef NDEBUG
# pragma comment (lib, "freeglut.lib")
# else
# pragma comment (lib, "freeglutd.lib")
# endif
# endif
so if you don't define NDEBUG, the linker will link to "freeglutd.lib",
you can solve that by defining a NDEBUG in "PreprocessorDefinitions".
Good luck!
Hey man I don't know if you're still having this error but here is a solution. Pretty much the "freeglutd.lib" has to do with debugging, hence the "d" on the end, so what I did was go into the:
Properties > C/C++ > Preprocessor > Preprocessor Definitions and type NDEBUG. Then OK and Apply.
What this does is in the "freeglut_std.h" there is a ifdef for NDEBUG that if it is defined then use "freeglut.lib" otherwise it's going to use the "freeglutd.lib". So by defining it in the Preprocessor Definitions, you are now using the "freeglut.lib". Hopefully this helps you out!
Possibly already answered: freeglut error LNK1104
Also two things to check for:
Are you building in debug or release mode? The d at the end of freeglutd.lib suggests that it's a library meant for debug builds
Try creating a new project from scratch, put some basic runnable code in it that uses freeGLUT and see if VS is linking properly. This will also verify if for some reason the project file of the previous project was corrupted (as #RobertHarvey suggested) or the problem is somewhere else
I solved this problem by compiling freeglut and freeglut_static from generated CMake soluton in Debug mode - freeglutd was created in the lib/Debug directory. You can put this directory into lib path then and it will work!
is there a tool in windows SDK to ckeck what CRT a library uses?
for example I have a *.lib file, how do check if it's compiled with /MDd flag or /MT?
also how to check the same for dll or exe?
can this be done with dumpbin?
If it is a .lib file, a static link library, then you don't know anything about the CRT yet. It wasn't linked yet. You can find out about the original programmer's intention, use a hex viewer to look the .lib file, Notepad will do fine as well. You'll see the original command line that was used to compile the .obj files that were embedded in the .lib file. Simply search for "cl.exe", you'll have a good idea what compiler version was used from the path to cl.exe. And you can see the command line options so you'll know if /MD or /MT was in effect. And the /O option, important to have an idea whether you've got a Debug or Release build.
If it is a .dll file then dumpbin.exe /imports is your best choice. The dependency on the msvcrxxx.dll file will be visible, with xxx the version number like "120". If you see it then the name tells you if /MD or /MDd was used, "d" is appended for the Debug version of the CRT If it is missing then you know that /MT or /MTd was used, no hint about the build flavor available.
Following the recommendations from the library owner is always best, you can get into a lot of trouble when the CRT version or build settings of the library doesn't match yours. With non-zero odds that you have to ask him for an update, YMMV.
I am currently digitizing old VHS cassettes. For post-processing, I would like to implement a custom algorithm with C++ & OpenCV. I have already implemented a promising prototype in Matlab, but it can only process single images (reading / writing video files is not possible in my version (R2010a); also, Matlab is far too slow).
Sadly, I am - over and over again - stuck with CMake. Though I wonder ... this can't be so difficult. I have often had problems with CMake, so I will go into a lot of detail here. I hope that you can not only point out to me what I am doing wrong here, but give general advices towards my usage of CMake as well. Maybe I am doing it all wrong, I don't know.
Here is what I've done so far:
I have downloaded the OpenCV 2.3.1 superpack from sourceforge. The superpack contains OpenCV source code, includes and - most importantly - the .lib and .dll files for all major platforms. For this reason, I need not build OpenCV myself. It is already done. I need only use/link it.
I installed (i.e. extracted to) the superpack in C:\dev\vs2010sp1_win32\opencv\2.3.1.
I have renamed C:\dev\vs2010sp1_win32\opencv\2.3.1\OpenCVConfig.cmake.in to OpenCVConfig.cmake.
I have created a folder for my project C:\dev\VhsDejitterizer with the following structure:
VhsDejitterizer/
CMakeLists.txt (A)
src/
CMakeLists.txt (B)
libvhsdejitter/
CMakeLists.txt (C)
vhsdejitter/
util.h
util.cpp
main/
CMakeLists.txt (D)
main.cpp
Here are the contents of the individual CMakeLists.txt files.
/CMakeLists.txt (A)
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT("VhsDejitterizer")
CMAKE_POLICY(SET CMP0015 OLD)
FIND_PACKAGE(OpenCV REQUIRED
NO_MODULE
PATHS "C:/dev/vs2010sp1_win32/opencv/2.3.1"
NO_DEFAULT_PATH)
ADD_SUBDIRECTORY("src")
/src/CMakeLists.txt (B)
ADD_SUBDIRECTORY("libvhsdejitter")
ADD_SUBDIRECTORY("main")
/src/libvhsdejitter/CMakeLists.txt (C)
UNSET(source_files)
FILE(GLOB_RECURSE source_files "*.h" "*.cpp")
ADD_LIBRARY(libvhsdejitter STATIC ${source_files})
TARGET_LINK_LIBRARIES(libvhsdejitter ${OpenCV_LIBS})
UNSET(source_files)
/src/main/CMakeLists.txt (D)
UNSET(source_files)
FILE(GLOB_RECURSE source_files "*.h" "*.cpp")
ADD_EXECUTABLE(main ${source_files})
TARGET_LINK_LIBRARIES(main libvhsdejitter ${OpenCV_LIBS})
UNSET(source_files)
Configuring and generating the Visual Studio .sln (...) files works well. In fact, I am not getting a single warning or error:
Configuring done
Generating done
However, my attempt to build the 'main' project in Visual Studio fails:
1>------ Build started: Project: main, Configuration: Debug Win32 ------
1>Build started 04.04.2012 14:38:47.
1>InitializeBuildStatus:
1> Touching "main.dir\Debug\main.unsuccessfulbuild".
1>CustomBuild:
1> All outputs are up-to-date.
1>ClCompile:
1> main.cpp
1>LINK : fatal error LNK1104: cannot open file '#CMAKE_LIB_DIRS_CONFIGCMAKE#/libopencv_gpu.so.#OPENCV_VERSION##OPENCV_DLLVERSION##OPENCV_DEBUG_POSTFIX#.lib'
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:00.59
========== Build: 0 succeeded, 1 failed, 2 up-to-date, 0 skipped ==========
Further details:
Operating system: Windows 7 Pro 64-bit
IDE: Visual Studio 2010 SP1
CMake version: 2.8.4
Target platform (i.e. what am I compiling/building for): Windows 32-bit
My questions:
How do I successfully build the 'main' project? I.e. how to fix that error?
What are these #VARIABLE_OR_SOMETHING#? I have tried to find out where they come from, and they seem to be set up in OpenCVConfig.cmake. But how are they supposed to work? Are they supposed to be evaluated by Visual Studio at "build-time"? If so, how are they evaluated?
You have probably noticed that I have set up quite a sophisticated folder structure. Do you have any advice on this? How do you organize your libraries and projects? Are there best-practices? Where are they documented?
Thank you and best regards, Robert
These variables are probably related to CMake's configure_file command, which allows you to specify a parameterised template document (typically with the extension ending in .in) and you can substitute CMake variables into the file to create it. They are evaluated at the time of the configure_file call, which happens when running CMake. I think what's happening is that there will be a parent CMake script to the one that you've taken which will configure that file with the contents of those variables and then use it in an add_subdirectory call. I would suggest checking for any readme that describes the top level run process (or any file which defines those variables then substitute them manually).
I have fixed it now. I think I can safely say that the whole mess was not my fault. Sorry for answering my own question.
Here is what I tried first (of course, this did not work for me, but it might work for others):
As Martin Foot pointed out in his answer, the *.in files are templates which are supposed to be filled out with proper values during a CMake configuration. However, I am using the OpenCV superpack, which includes all the binaries. For this reason I have, at no point, performed such a configuration step, because I assumed this would only be necessary if you wanted to compile something.
However, it seems that - even if you're using the superpack with prebuilt binaries - you have to configure the project in order to get your OpenCVConfig.cmake generated. Vadim Pisarevsky has stated that in the OpenCV bug tracker.
For some reason, this didn't work for me. I started up the Cmake GUI as usual, pointed it to the OpenCV directory and hit "Configure". I even hit "Generate" out of desperation. Yet, no OpenCVConfig.cmake appeared.
So I had to go on further ...
This is what actually helped:
In a recently filed bugreport related to OpenCVConfig.cmake, Sergiu Dotenco pointed out "that the currently provided OpenCVConfig.cmake is pretty fragile" etc. etc. Fortunately, Sergio has also provided a custom FindOpenCV.cmake script. By using his script I have finally been able to generate a working Visual Studio solution.
By the way, this is my current top-level CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT("VhsDejitterizer")
SET(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake-modules" ${CMAKE_MODULE_PATH})
SET(OPENCV_ROOT_DIR "C:/dev/vs2010sp1_win32/opencv/2.3.1")
#SET(OPENCV_USE_GPU_LIBS ON)
FIND_PACKAGE(OpenCV REQUIRED)
ADD_SUBDIRECTORY("src")
I have installed Sergio's FindOpenCV.cmake script in a new cmake-modules/ subfolder of the project. It is also important to note that I am using (as opposed to my original setup, where I used the "config mode") the minimal FIND_PACKAGE variant ("module mode"). Only if the minimal variant is used, CMake is looking for Find<package-name>.cmake scripts in the CMake module path. See the CMake documentation for FIND_PACKAGE.
I have also found this guide, which is about how to properly use CMake if you're a library developer: http://www.vtk.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
I have fixed it now. I think I can safely say that the whole mess was not my fault. Sorry for answering my own question.
You fixed it?
I am having the same problem, and I followed your solution but it did not work.
When CMake executed the command
FIND_PACKAGE( OpenCV REQUIRED )
It would output:
One or more OpenCV components were not found:
calib3d
contrib
core
features2d
flann
highgui
imgproc
legacy
ml
objdetect
video
CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE):
Could NOT find OpenCV (missing: OPENCV_CALIB3D_LIBRARY
OPENCV_CONTRIB_LIBRARY OPENCV_CORE_LIBRARY OPENCV_FEATURES2D_LIBRARY
OPENCV_FLANN_LIBRARY OPENCV_HIGHGUI_LIBRARY OPENCV_IMGPROC_LIBRARY
OPENCV_LEGACY_LIBRARY OPENCV_ML_LIBRARY OPENCV_OBJDETECT_LIBRARY
OPENCV_VIDEO_LIBRARY) (found version "2.3.1")
Finally, I used the commands
include_directories
TARGET_LINK_LIBRARIES
to include all necessary directories or files, and it works, in a awkward way!
I am trying to run FFTW code in a mex file. This is strictly for the purpose of development and testing. After some googling, I see that others have tried to do something similar and have had related problems, but I have not found any solutions. When attempting to run the mex file, Matlab tells me:
??? Error using ==>
chirpTransform.mxCta Invalid MEX-file
'\removed\my\directory\+chirpTransform\mxCta.mexw32':
The specified procedure could not be
found.
.
I am using gnumex with MinGW to build the mex file because LCC seems to have some issues. I have tried using the 32 bit DLL from the FFTW site (http://www.fftw.org/install/windows.html). I have tried using the fftwf3.dll in the Matlab 2009b bin directory. I built the dll from source using Msys/MinGW. In all cases, the results are the same. In all cases I did the following to generate the lib file.
c:\gnumex\mexdlltool.exe -d
libfftw3f-3.def -D libfftw3f-3.dll -l
libfftw3f.lib --as C:\MinGW\bin\as.exe
I also tried using the visual studio lib.exe tool and experimented with various mexdlltool flags.
It appears that I can directly call functions in the fftwf3-3.dll using Matlab's loadlibrary functionality. Since the DLL appears not to be the problem, I tried building a static version of fftwf3 and linking it directly into the mex file. I got the same results! If I remove the FFTW code, the mex file runs fine. I have just about given up at this point, and I am tyring to come up with alternative methods of testing.
I've run into this issue with other mex functions. In my experience, it typically means that there is a dependency issue. Some dependency is not located.
Here is a link to TMW's documentation on this issue:
Invalid MEX-File Error
Give it a read, and then try using dependency walker to diagnose the problem.
It's been a long time, and my setup has changed, but this works for me now. I suspect hoogamaphone was right. I probably didn't have the fftw dll in the same directory as the mex dll (and it wasn't in my path). In fact, 64 bit Matlab 2016a still gives you a warning about not being able to find the mex file when, in fact, it's a dependency that's missing.
My current setup is using the Visual Studio 2013 C++ compiler by default. As mentioned on the fftw web site, you need to generate a lib file for linking. You can run the Visual Studio command prompt from a regular command prompt like so:
"%VS120COMNTOOLS%VsDevCmd.bat"
Then run the following in the directory with the def file.
lib /machine:x64 /def:libfftw3f-3.def
And compile.
mex mxCta.c cta.c -I../fftw -L../fftw -llibfftw3f-3.lib
Perhaps another possibility is that gnumex introduced some dependency into the mex dll. I no longer recall whether I had used gnumex successfully testing other code. When using cygwin, if you don't use the mingw compiler (x86_64-w64-mingw32-gcc), you'll end up with a dependency on the cygwin1.dll.
Finally, if you use more than one compiler, make sure all the compiler flags are the same (same function calling conventions, ABI, etc). Also, Mathworks has changed the mex build procedure. In a recent project, I copied mexconfig.xml to my local directory from
C:\Users\myuser\AppData\Roaming\MathWorks\MATLAB\R2016a\mex_C_win64.xml
and edited the compiler flags like so:
COMPFLAGS="/Zp8 /GR /W3 /EHs /nologo /MD /Gz /TC"
If you use a custom build file, use the -f option.
mex mxCustom.c custom.lib -f mexconfig.xml