I have a Cmake/wxWidgets project that builds fine on my pc.
I compile wxWidgets using nmake /f makefile.vc BUILD=release TARGET_CPU=X86 and generate the CMake project using cmake .. -G "Visual Studio 16 2019" -A Win32 -DCMAKE_CONFIGURATION_TYPES=Release.
Like I wrote, this compiles fine on my pc. When I want to build it using a github action on Windows 2019 Image I first pull wxWidgets, compile it using the above statement, generate wxWidgets using the aboce statement and trigger the build using a cmd-script containing "%programfiles(x86)%\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild.exe" ".\build\NaCl-Configurator.sln" /p:Configuration=Release /p:Platform=Win32 /p:PlatformTarget=x86
But when doing this I always get the following error:
wxmsw31u_core.lib(corelib_wincmn.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'x86' [D:\a\abc\abc\build\abc.vcxproj]
If I switch everything to x64 it compiles fine, but I need a x86 build. Is there any system setting I'm missing?
This is not an answer, this is a recommendation.
But after spending hours looking into your issue, I am seriously pulling my hair at the Microsoft documentation for MSBuild.
Just use Ninja. This is what we use to build our x64/x86 binaries.
You might need to learn a little bit about cmake toolchains, but at least you don't have to deal with this msbuild nonsense.
Ninja is faster, works much better with cmake, is a very tiny executable, etc.
Seriously using msbuild/visual-studio on your servers isn't worth it.
Again I apologize this isn't a direct answer to your question, if you do continue down this path I'm curious to see the answer.
====================================================
What I found out though:
I will say I'm very confused about the difference between PlatformTarget and Platform. Because all the visual studio solutions I generate don't even have PlatformTarget as a property anywhere. I scanned the generated solution files and didn't see this anywhere. Granted I'm using vs2019 so maybe it's deprecated I dunno.
Prefer to expand the /p -> /property that's just good practice for your build server scripts.
Perhaps try using the platform property "x86" instead. I literally couldn't find concrete information on which was preferred/correct. Win32/x86.
And as a final guess please start printing out your compiler, and toolchain information from cmake.
Resources:
How do I specify the platform for MSBuild?
https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-target-framework-and-target-platform?view=vs-2019
Me looking at the msbuild command line, and looking at my generated visual studio solutions.
I was using another github action to access nmake to build wxWidgets. Within this action I had to specify the architecture.
So using
- name: Preparing nmake
uses: ilammy/msvc-dev-cmd#v1
with:
arch: x86
- name: start building wx widgtes
run: |
cd ${{ env.WXWIN }}${{ env.wxMSW_VER }}\build\msw
nmake /f makefile.vc BUILD=release TARGET_CPU=X86
and then going on did the trick. It was only the with: arch: x86 that was missing
Related
Context:
I am following the guide for the open source project OpenSC https://github.com/OpenSC/OpenSC to compile the solution on Windows and get the opensc-pkcs11.dll module to use it for communications (such as OpenSSH) with HSM's via PKCS#11 standard. Currently I am using the latest stable release 0.21.0 (msi installer) and it works perfectly. However when I use https://github.com/OpenSC/OpenSC/wiki/Compiling-on-Windows guide to compile the solution using Visual Studio Developer Command Prompt I can successfully build the libraries however the opensc-pkcs11.dll always returns pkcs11: 0x5: CKR_GENERAL_ERROR when I try to use it and I am not sure what am I missing here.
Setup:
git clone https://github.com/OpenSC/OpenSC.git
git checkout 30180986a08cf71fe4af4b50251a8bb5b1ab95af (0.21.0 commit for the right version)
Manually Creating Built Source Files
nmake /f Makefile.mak
Building it for x64, with x64 Native Tools Command Prompt for VS 2019.
That should be it according to the guidelines as I do not need openpace/openssl/zlib to compile the opensc-pkcs11 as far as I understand.
Problem summary:
If I download from releases https://github.com/OpenSC/OpenSC/releases version OpenSC-0.21.0 the compiled opensc-pkcs11.dll works as expected
If I compile it from source code based on v0.21.0 commit I get 0x5: CKR_GENERAL_ERROR when trying to use the library for e.g. OpenSSH, tested that this happens for other/previous commits as well, there for I suspect that I am missing something here.
Has anyone experienced the same issue? Maybe there is some build config anyone could share so I can understand what am I missing here?
Background: I work in a company with many preferences. We currently use makefiles for our complex build with the developer's choice of IDE (or even VIM) for editing source files.
I'm looking at CMake to clean up our un-tame-able gnu make build system. I like the integration with VS Code, but I couldn't possibly manage to dictate the IDE to many of our more prickly DSP engineers and their preferred editing environment (which I totally understand; I'm a bit of Visual Studio guy, myself).
Anyways, is the cmake-kits.json method of specifying kits or toolchains/targets/etc. the "right" way to do it? Or is that just for VS Code.
If it's just for VS Code, what's the proper CMake-y way to put in new toolchains (we do cross compiling using non-gnu tools for 3 different processors) that would work in VSCode, or eclipse, or from the command line.
Kits are part of the CMake extension for VS Code. You want to read cmake-toolchains(7). A kit is something like setting CC and CXX in the environment so CMake knows which compiler to use for Makefile and Ninja generators. It is different for the other generators as the IDE can control which exact compiler is used and you tell CMake which toolset to use and it generates the project accordingly. FYI, kits don't handle having to write your own toolchain file for cross compilers.
You can use a toolchain file for cross compiling. This can be simple to hard depending on the compiler and how well it acts like a gcc cross compiler. If it's really different a toolchain file isn't quite enough as you then need to update the platform items to get it all working. Since this gets into the area of being CMake implementation dependent it's not that well documented. But there is help at https://discourse.cmake.org/.
You could just use Ninja as the build tool. Then you setup your toolchain file. After your original run on CMake to create the Ninja project files, you can just run Ninja to build the software.
Then it's easy to set your IDE to just call Ninja to build the software.
Personally, I don't like the CMake integration in VS Code (it's just an add-on). It's always been too buggy for me to want to use it. But it was good for pulling the information out of the build to get the cpp-tools setup correctly. As for project files for Eclipse CDT4 - Ninja I've never personally used them.
I have testaddin.vdproj .I am trying to generate the .msi from that in cmake.But i don't know what command to execute in cmake add_custom_command.Please provide any solution for this problem.
Thanks in advance.
I've never used cmake but I can tell you the only way to build .vdproj projects is by calling devenv.com /rebuild with the correct parameters for your solution / platform / configuration settings. Visual Studio deployment projects aren't MSBuild based so there is no other way to do it. Perhaps CMake has a higher level abstraction for this but under the covers this is what it must do.
I am compiling the OpenCascade Community Edition (https://github.com/tpaviot/oce/) on Windows 7. The build files are generated with CMake 2.8.8.
When I use the "Visual Studio 10" generater and compile the projekt with msbuild from a console the whole build process takes 17 minutes. On the other hand, if I select "Eclipse CDT4 - NMake Makefiles" and start the build process in Eclipse, it takes 87 minutes.
Does anyone know the reason for this difference? Is there a way to make the Eclipse build much faster?
With msbuild I do NOT use parallel builds. Also when I take a look at the task manager it seems as if the CPU usage of both build processes is nearly the same.
I have searched a lot, but did not find any clue. Thank you in advance.
Yes, VS IDE projects do parallel builds. nmake does not. One think you could try is jom or some other tool, see here for information:
http://www.kitware.com/blog/home/post/434
I did not notice that you said msbuild is not doing parallel. How did you do that? It will be default do parallel target builds.
My buildbot has been running for 3 years using devenv.com to compile the projects on Windows.
Now devenv.com has troubles to build for 64 bits versions: passing the configuration as "Debug|x64" generates command line errors because of the pipe character. Escaping and enclosing between quotes result into other errors, some because of the spaces in the directory names, some because of strangely understood command line.
I tried both vcbuild.exe, and MSBuild.exe. vcbuild.exe works perfectly: I'd like to stick to it. MSBuild.exe, on the other side, has a completely strange and complicated output that my coworkers feel terrible. But it is touted everywhere as THE way to build.
The question is: which of devenv.com, vcbuild.exe, and MSBuild.exe is the method that is most likely to last in time?
MSBuild (before Visual Studio 2010/.NET 4) doesn't itself build C++ projects. It calls out to vcbuild.exe. So if you are happy not using MSBuild then I would stick to that for the C++ projects. For managed projects (and for C++ using VS 2010) use MSBuild.
MSBuild is the method "most likely to last". VCBuild.exe is dead; it's last release was 2008. MSBuild 4.0 will still use it, if it needs to build a VC project from VS2008 or earlier. As for devenv.exe -- of course, it's just headless Visual Studio. Functionally it is the same as hitting build in VS. That means that these days, it's essentially just handing off to MSBuild, but sometimes with less parallelism than msbuild.exe will get. The main reason you might still have to use devenv.exe is .vdproj (Deployment) projects. These legacy things have a build process hard coded into VS. I recommend an alternative like WiX or Installshield which are MSBuild based. Not long now until everything build in VS is MSBuild.
In short -- MSBuild is the future, use it unless you have deployment projects or other special circumstances.
Dan
I ran into the same problem, and solved it by Windows-shell-escaping the pipe character:
"Debug^|Win32"
msbuild.exe does not (did not?) know how to build setup projects. devenv.exe does.