I understand that CMAKE_BUILD_TYPE only works for single-configuration generators like Unix Makefiles. There are also multi-configuration generators like Visual Studio or Xcode where CMAKE_BUILD_TYPE does not works. (see this and this question for further info). I've generated Visual Studio 2013 x86 project with cmake-gui for libharu and there is not possible to switch from win32 to x64 in Visual Studio. I'm wondering why in multi-configurations it is need to specify architecture (x86 or x64) in cmake? Why it is not possible in Visual Studio directly? Is there some limitation or benefit or something that I should be aware of?
Thanks
Because this switch between 32 and 64 bit is not available in all environments cmake follows the philosophy to use out-of-source builds and have each compiler in their own directory. So a 32 bit and a 64 bit build can be seen as a a different compilation environment so they each generate their own folders.
So while this is a cmake limitation it is also intentional.
This answer also mentions this: https://stackoverflow.com/a/5359191/152359
Related
I'm using Windows 10 Pro, Visual Studio 2022 and cmake version 3.26.0-rc3. In my Visual Studio solution I have a static library project, let's call it MyLib, which uses features from libxml2 i.e. it needs to link against libxml2.lib. Also in my solution there is an executable project, let's call it MyExe, which links against MyLib and also has libxml2.lib listed as a dependency in its project settings.
The problem is that in the CMakeLists.txt file of MyLib, target_link_directories and target_link_libraries do not seem to have any impact on the MyLib project settings, particularly Additional Library Directories and Additional Dependencies, respectively. For MyExe, those commands work as expected. If I fix the linker options for MyLib project settings manually in Visual Studio IDE, everything builds fine, but I don't think I should need to manually alter project settings initially created by CMake. So is there something I'm missing here - like that dependencies for a static library project need to be set in a different way in CMake - or is this a bug in CMake or Visual Studio? Are there any alternative ways to achieve the desired behavior and get the build to work?
In trying to find solutions for this I came across this very old post, but if I understood correctly it suggested adding an extra library project which sounds like a huge overkill for a simple thing like this which could be worked around by setting the project settings manually in Visual Studio IDE, so it's not an acceptable solution for me.
I've set up a build process in Visual Studio Team Services for a UWP solution using an agent on my box. My solution contains a mix of C++ and managed projects (2 projects are C++, other are C#). My problem is that x86 build fails, while for x64 and ARM platforms the build completes successfully.
From what I'm seeing from the build log, it is incorrectly treating Win32 platform as x64, and putting the resulting *.lib file into bin\Release\x64 folder instead of bin\Release\Win32, where the next project is supposed to pick it up from:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\Lib.exe /OUT:"C:\Agent\_work\1\s\MyProj\MyProject1\bin\Release\x64\MyProject1.lib" /NOLOGO /LTCG C:\Agent\_work\1\s\MyProj\MyProject1\obj\Release\x64\test.obj
Any suggestions on how to fix that are greatly appreciated.
The issue was happening because I didn't have multi-configuration set up. To be able to build the solution for multiple platforms/configruations, this is a mandatory setting. When I got that set, the build started to succeed.
I use API to make a programs. It runs pretty well on Windows 7 (with debug file .exe), but it doesn't when I run it on Windows XP. Are there any ways to solve this problem?
I suppose you are using Visual C++, according the the message you get.
Your project is set up (by default) to link the Microsoft C++ Runtime Librairy dynamically, so it saves up space in your final executable, but you need the dynamic linked libraries to be in your system or in your executable's folder.
To solve this in Visual C++, without any afford from who are executing the program in their machines, you can change how MSVC link their runtime library to your executable, that is, if you set it to be linked statically, all the dependencies will be linked inside your final .exe, with no need of additional .dlls.
To change this option, refer to /MD, /MT, /LD (Use Run-Time Library) - MSDN.
Or in short: Project Properties>Configuration Properties>C/C++>Code Generation>Runtime Library
If in debug mode, use /MTd, otherwise use /MT.
I am creating a wrapper around a native lib, which comes in both 32 & 64 bit flavors. I have a fairly complex C++/CLR project that includes a number of header files from the native libs. I got it to work fine on x32, but now I'm not sure how to provide an alternative x64 build.
Can someone outline the steps to create such project?
Various defines depend on _WIN32 / _WIN64, so must be multiple projects?
Both x32/x64 native libs have identical file names. Currently the lib ref is done with #pragma comment (lib, "xxxxxx.lib"). How should this be changed?
Lastly - VS2008 has only Win32 platform listed, not Win64 (I do have x64 VS2008 component installed).
Thanks!
Normally it is sufficient to select the drop down which says win32 (next to the Debug/Release one on the toolbar) and selected "Configuration Manager". Then open the "Active Solution Platform" drop down and select New. Choose x64 type (which if it doesn't exist then 64bit compilers are not installed) and copy solution from the orignal Win32 one. Now your project can be built selectively by changing the drop down on the toolbar.
Normally it works more or less as is but you might want to consider tweaking a few pre-processor defines if only for the intellisense.
As for libraries, for platform ones (supplied as part of VS/PSDK) then you dont need to change anything. For your libraries you are wrapping then change the Additional Library Directories in the project properties to point to the 64bit directory.
Visual studio doesn't always install the 64 bit options.
It can be fixed by running the VS installer, choosing add/remove features, and checking the x64 feature.
Is it possible to build Visual Studio solutions without having to fire up MonoDevelop?
Current status (Mono 2.10, 2011): xbuild is now able to build all versions of Visual Studio / MSBuild projects, including .sln files. Simply run xbuild just as you would execute msbuild on Microsoft .Net Framework. You don't need Monodevelop installed, xbuild comes with the standard Mono installation.
If your build uses custom tasks, they should still work if they don't depend on Windows executables (such as rmdir or xcopy).
When you are editing project files, use standard Windows path syntax - they will be converted by xbuild, if necessary. One important caveat to this rule is case sensitivity - don't mix different casings of the same file name. If you have a project that does this, you can enable compatibility mode by invoking MONO_IOMAP=case xbuild foo.sln (or try MONO_IOMAP=all). Mono has a page describing more advanced MSBuild project porting techniques.
Mono 2.0 answer (2008): xbuild is not yet complete (it works quite well with VS2005 .csproj files, has problems with VS2008 .csproj and does not handle .sln). Mono 2.1 plans to merge the code base of mdtool (MonoDevelop command line build engine) into it, but currently mdtool is a better choice. mdtool build -f:project.sln or man mdtool if you have MonoDevelop installed.
for now as per August 2017 we can use
msbuild
command as xbuild is depreciated.
xbuild now supports solutions and projects, both VS2005 and VS2008.
I think you are looking for xbuild:
http://www.mono-project.com/Microsoft.Build