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.
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.
Lately I have challenged myself to build the Eclipse IDE from the source code. This will open an opportunity to start playing around with the code, and make some changes.
I found the following tutorial to guide me through the procedure: http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html
Especially chapter 13 of that Tutorial is helpful. Apparently I need to have the following software installed on my (Windows) machine:
Git
Maven Version 3.3.1 (make sure that the bin folder where you extract Maven is added to the PATH)
Oracle 1.8 JDK or higher
I have all this software on my desktop - so I'm ready to go. I start by cloning the newest Eclipse repository and it's submodules via Git to some folder on my machine:
git clone -b master --recursive git://git.eclipse.org/gitroot/platform/eclipse.platform.releng.aggregator.git
This takes a couple of minutes. Maybe half an hour at most. Eureka - the folder is now pretty full with the Eclipse source code! The vogella tutorial proceeds with the actual build command. I open the command prompt in Windows and surf (cd..) to the right spot. Then I type the command:
mvn clean verify
I first got some errors. But thanks to the StackOverflow community, they are solved now. Please refer to this link for more info: https://stackoverflow.com/questions/37645180/building-the-eclipse-ide-from-scratch
Eclipse builds. And it builds. And it keeps building for hours. After many hours, I get the message that the build has finished. I'm amazed it took such a long time, since my computer is quite a beast:
> CPU: Intel Core i7-4790K CPU #4.00GHz
> RAM: 16.0GB
> System type: 64-bit OS
> Windows 10 Home
Anyway, after the build has finished, the JUnit testing automatically starts. I have no option to skip it. I wait for some more hours, until I really need to stop the system and go home. I close the command prompt - knowing that I interrupt the JUnit testing. But who cares :-).
I check my filesystem, and cannot find the files about which the Vogella tutorial speaks:
eclipse.platform.releng.tychoeclipsebuilder/sdk/target/products/*
Help.. was the whole build procedure done for nothing? I want to redo the build, but is there a way to skip those JUnit testings?
EDIT: I followed the advice of Mr. Gerold Broser and added the -DskipTests flag to the mvn clean verify command. I believe that Eclipse is now building without doing all the JUnit testing. Nevertheless, I still feel like the build takes an eternity. I'm now waiting for 4 hours. Is this normal? Are there ways to tell the maven build tool that it can use all 4 CPU cores?
EDIT: The Eclipse build has finally stopped. Unfortunately, it is no big success. I get a very lengthy error message. The build has failed. I've opened up another StackOverflow post to get some help:
https://stackoverflow.com/questions/37662645/building-eclipse-from-scratch-build-failure
Hope you can help me out.
See Maven Surefire Plugin / Skipping Tests:
You can also skip the tests via the command line by executing the following command:
mvn ... -DskipTests
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.
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.