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.
Related
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
I´m trying to build paraview from source, therefore using:
Windows 7
Visual Studio 2010
Qt 4.8.7
Python 2.7.8
msmpi 7
paraview source, version 5.1.0
In CMake I can choose different options to specify what functionality to include into the build process. I tried different combinations, like setting BUILD_EXAMPLES or PARAVIEW_USE_MPI, respectively. Now I have got following questions:
When I set BUILD_SHARED_LIBS and PARAVIEW_ENABLE_PYTHON as well (besides others), configuring and generating the project with CMake is successful, but compiling in VS fails; it keeps freezing right after starting the compilation. Did anybody experience the same problem and how did you solve it? (By the way, if I unset BUILD_SHARED_LIBS it works, but I don´t want a static build of Paraview).
By using the combination BUILD_EXAMPLES, BUILD_TESTING, PARAVIEW_BUILD_QT_GUI, PARAVIEW_ENABLE_CATALYST, PARAVIEW_ENABLE_PYTHON and PARAVIEW_USE_MPI the same problem as described in 1.) occurs, but that is more or less what I need to use Catalyst to perform in-situ analysis of my FEM simulation. (Incidentally, if I unset BUILD_TESTING in the above combination it works, but I need CTest to test the Catalyst examples as described here. Does anybody now how to fix that problem?
As shown at GitHub, some examples have been updated to work properly in Paraview 4.4. Is my version of Paraview (5.1.0) unsuitable for the Catalyst examples? Is that the reason why VS is always hanging up for particular variable settings in CMake and which version of Paraview is most suitable to get the Catalyst examples going?
I'd appreciate any help!
That's odd! There's no known reason for this. Although I haven't used VS2010 explicitly, we do have dashboards testing with 2013 and I build with VS2015 with no issue.
I'd recommend using the Ninja as the builder rather than the IDE, however. Just run cmake-gui.exe from appropriate VS studio command prompt and pick Ninja as the build generator. Then, to build, just run ninja in the build directory.
I am writing a script that pulls files from my development folders and would like to generate an installer with those files.
I would like to if there is a way to create MSI installers using command line.
Yes there is a way. The very flexible Windows Installer XML Toolset. A pretty good tutorial on how to use it is this link
The toolset is here
I think you need to define "create". If you mean "build" or "compile" then yes, pretty much every MSI authoring tool out there supports some form of automated build ... usually even MSBuild support.
If you mean "author" and "build" it's technically possible but not usually advised. Installation is too complicated to be auto magically developed.
I was trying to use Nuget as a software deployment system (repository, versioning and delivery) - idea from Octopus. Previously I was packaging ASP.NET sites into a self-extracting RAR archives with a .CMD startup scripts embeded. Now I'm trying to use Nuget creating puckages during automated build. The issue is that the package installation scripts (tools\Install.ps1 or tools\Init.ps1) do not execute if the package is being installed using command line:
nuget.exe install <package_id> -OutputDirectory <install_folder> -source <local_repo>
Same scripts are able to execute when package installed from Visual Studio Package Manager or Console.
I do not see why this shouldn't be possible given omnipresence of PowerShell.
Am I missing something or this is behaviour by design? Will appreciate you help.
Yes, we did consider MSDeploy but we already have install scripts that do the same thing and give more control and we need some strong package management and repository for build artifacts (something that Java folks do with Maven).
As of today, the powershell scripts are not invoked from doing installations from command line.
One reason for this is that, in general, most of the install/init actions are tied to dte and the visual studio project and doesn't add much value to be able to run it from outside VS.
We have a backlog item for enabling support for exe based scripts too in addition to powershell.
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.