we're using qmake and *.pro files to generate Visual Studio project files, currently 2 files one for x86 and one for x64. To achieve this we're using a script which first sets the environment variables (e.g. %QTDIR%) for x86, calls qmake after that to generate x86 *.vcxproj and repeat that for x64 (set and call).
setEnvVariables("x86")
cmd /c "$env:QTDIR\bin\qmake" -Wall -tp vc -o "myProj.vcxproj" myProj.pro
setEnvVariables("x64")
cmd /c "$env:QTDIR\bin\qmake" -Wall -tp vc -o "myProj_$platformextension.vcxproj" myProj.pro
We've different lib/include paths for Qt x86 and x64 (Qt4.8.7 and Qt4.8.7_x64).
My question now: Is there a way to force qmake to generate a single project file for both platforms so we can use MSBUILD on a single project file? E.g. msbuild myProj.vcxproj /p:Configuration=Release /p:Platform=x64 and next step msbuild myProj.vcxproj /p:Configuration=Debug /p:Platform=x86.
Could I archieve this with special *.pro and *.pri setup?
Related
So I need to support .usd/.usda/.usdc for my renderer application, and I need to distribute the resulting project .exe and usd .libs/.dlls to our users on install. How do I build the library in a way that I can distribute? If I can't distribute it due to how the library is structured, how do I have the user install the needed dependencies automatically?
I was able to get oneTBB I believe (as TBB is a dependency of the library, but I don't know if USD can use it, here is how I compiled it)
::Issue this creates a .dll, would have been nice to have a static lib for not needed function culling
download: https://github.com/oneapi-src/oneTBB
extract: oneTBB-master folder
copy: include folder to destination (/I.\include in cl command when compiling)
open: cmd inside oneTBB-master folder (TIP: if you type cmd and hit enter in the folder path in the top it opens cmd there)
run: mkdir build && cd build
::if you want HWLOC then you need to rebuild with TBB bindings (for OpenMPI, I believe, but we don't currently use)
run: cmake .. -G "Visual Studio 15 2017 Win64" -DTBB_TEST=OFF -DCMAKE_CXX_STANDARD=17 -DCMAKE_BUILD_TYPE=Release
run: cmake --build . --config Release
run: cd msvc_19.16_cxx17_64_md_release
copy: tbb12.dll to destination
copy: tbb12.lib to destination (link against this)
:: don't think we need tbbmalloc.dll/tbbmalloc_proxy.dll and tbbmalloc.lib/tbbmalloc_proxy.lib
I tested TBB by compiling on the command line with a simple test program and build script like
#echo off
if not defined DevEnvDir (
call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvars64.bat"
)
set FILES=MinimalTBB.cpp
set LIBS=kernel32.lib user32.lib gdi32.lib
set DLLLIBS=tbb12.lib
:: tbbmalloc.lib tbbmalloc_proxy.lib
cl /nologo /W3 /Z7 /GS- /DEBUG:none /Gs999999 /MT /EHsc /O2 %FILES% -FeMinimalTBB.exe %LIBS% /I.\include /link %DLLLIBS% /incremental:no /opt:icf /opt:ref /subsystem:console
But then I need to do Boost.
And then I would love to do something like:
download: https://github.com/PixarAnimationStudios/USD
extract: USD-release folder
open: cmd inside USD-release folder
run: mkdir build && cd build
run: cmake .. -G "Visual Studio 15 2017 Win64" -DBUILD_SHARED_LIBS=ON -DPXR_BUILD_MONOLITHIC=OFF -DPXR_BUILD_IMAGING=OFF -DPXR_BUILD_USDVIEW=OFF -DPXR_ENABLE_PYTHON_SUPPORT=OFF -DPXR_BUILD_DOCUMENTATION=OFF -DPXR_BUILD_TESTS=OFF -DPXR_VALIDATE_GENERATED_CODE=OFF -DPXR_BUILD_PRMAN_PLUGIN=OFF -DPXR_BUILD_ALEMBIC_PLUGIN=OFF -DPXR_BUILD_DRACO_PLUGIN=OFF -DPXR_ENABLE_MATERIALX_SUPPORT=OFF -DCMAKE_BUILD_TYPE=Release
run: cmake --build . --config Release
to get .dll which i will distribute along with the .exe and then just link against the .lib in my project without the user installing anything
As an aside: I saw nVidia has a precompiled version too, I tried compiling with it, but it threw a bunch of python36.dll missing errors, when I am not even using python (only c++).
I found a ok solution from compiling from the command line, there is probably a much better way to do this, but to get it going here is what I did
The following wastes lots of memory on ur build machine, lots of files that don't need to be there, so go through and remove them:
download: lastest repo to C:\USD and create a USD-install folder inside of it
run: "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\Build\vcvars64.bat"
run: py C:\USD\build_scripts\build_usd.py C:\USD\USD-install --no-docs --no-embree --no-python --no-debug-python --no-draco --no-prman --no-materialx --no-alembic --no-hdf5 --no-opencolorio --no-openimageio --no-usdview --no-openvdb --no-ptex --no-imaging
I am compiling a windows program from the command line, so I created a new cpp project, but since we are compiling inside of Fuzor do not worry about this step
copied over the C:\USD\USD-install\bin, C:\USD\USD-install\include, and C:\USD\USD-install\lib folder to place of build. (copied .\include has to be included in include path)
moved tbb.dll, usd_ar.dll, usd_arch.dll, usd_gf.dll, usd_js.dll, usd_js.dll, usd_kind.dll, usd_pcp.dll, usd_plug.dll, usd_sdf.dll, usd_tf.dll, usd_trace.dll, usd_usd.dll, usd_vt.dll, and usd_work.dll all from lib folder to the level where my .exe will be generated and run from
In usd/pcp/types.h on line 119 change the numeric_limits<size_t>::max() to SIZE_MAX and in base/gf/ilmbase_halfLimits.h comment out the min and max functions on line 66 and 67
I then linked against lib/tbb.lib lib/usd_tf.lib lib/usd_sdf.lib lib/usd_vt.lib lib/usd_usd.lib
Create a resources folder at level of .exe and copy C:\USD\USD-install\plugin\usd\plugInfo.json to resources folder
In lib copy over C:\USD\USD-install\lib\usd up to the .exe level
distribute .exe, .dll's, and resources folder
Why do I have to set a source .asm file's Properties > General > Item Type to Microsoft Macro Assembler, even though I had already selected for the project node, the option Build dependencies > Build Customization > masm.
It may depend on which version of Visual Studio you are using, but I recall what seemed like a one time option to auto-select masm for .asm file with one of the versions. After dealing with multiple versions of Visual Studio and having issues with some versions, I manually set the properties for each .asm file to use a custom build tool (also turn off does not participate in build as commented by John Kalane), which is working for all the versions I have (VS2005, VS2010, VS2015, VS2019).
32 bit debug build, for release build /Zi is not needed:
command line: ml /c /Zi /Fo$(OutDir)\example.obj example.asm
outputs: $(OutDir)\example.obj
64 bit debug build, for release build /Zi is not needed:
command line: ml64 /c /Zi /Fo$(OutDir)\example.obj example.asm
outputs: $(OutDir)\example.obj
I would like to convert my project from a Visual Studio solution to build with CMake and compile it with Makefiles.
This is a 2-part question.
Right now the CMakeLists.txt is:
cmake_minimum_required(VERSION 3.13.0)
project(Project2015 CXX)
add_executable(Project Source/main.cpp)
When I run cmake .. out of the build directory, it generates *.vcxproj and *.sln files, but there is no Makefile. How can I change the CMakeLists file to generate a Makefile?
What is the command line equivalent compiler to gcc for windows? And how do I set this compiler as the target for CMake and the generated Makefile?
Reading about the build tools https://learn.microsoft.com/en-us/cpp/build/walkthrough-compile-a-c-program-on-the-command-line?view=vs-2019
Do I need to target the cl.exe compiler? Would this work with CMake and Makefiles?
I'm reading online that these command line flags will set the compiler, how can I add these to the CMakeLists.txt to be used automatically?
DCMAKE_C_COMPILER=cl
DCMAKE_C_COMPILER_FORCED=ON
DCMAKE_CXX_COMPILER=cl
DCMAKE_CXX_COMPILER_FORCED=ON
DCMAKE_BUILD_TYPE=Debug
DCMAKE_INSTALL_PREFIX=%CFITSIO_DIR%
G"NMake Makefiles"
You should use the build tool mode of CMake for builds from the command line.
After configuring your project for a 64bit build using Visual Studio 2019 e.g. with
cmake -S <sourcedir> -B <builddir> -G "Visual Studio 16 2019" -A x64
you would run
cmake --build <builddir> --target ALL_BUILD --config Release
For further options see here for an almost quiet build from the command line see here.
As suggested by #vre, you can run everything from the command line, while still using the Visual Studio generator. Just use CMake's command line build tools:
cmake ..
cmake --build . --config Release
This way, you don't have to open Visual Studio at all to build your libraries/executables.
Another option is to use Microsoft's nmake utility, which will generate NMake Makefiles. You can tell CMake to use this generator instead using this:
cmake -G"NMake Makefiles" ..
The full list of CMake generators you can choose from is listed here.
If you don't want to manually set the CMake generator in the command line, you can set it at the top of your CMakeLists.txt file:
set (CMAKE_GENERATOR "NMake Makefiles" CACHE INTERNAL "" FORCE)
It will be used on the second CMake configuration in this case, as the first run will use the system default generator. If you want CMake to use it on the first configuration, you can utilize the Preload.cmake procedure outlined in this answer.
I am trying to build the components of Live555 with Visual Studio 2013 64bit on Windows 7.
I have tried editing win32config and the *.mak files without success. I've been searching the internet for a few hours and trying all kinds of things with command prompts.
For some reason VS2013 x64 command prompt is still building 32bit static libs and I can't figure out why.
If anyone has any good ideas, that would be fantastic!
The win32config file that you get from the .tar.gz file requires substantial editing to make it compatible with recent SDK and MSVC++ releases. This is a version that produced a clean build:
NODEBUG=1
TARGETOS = WINNT
UI_OPTS = $(guilflags) $(guilibsdll)
CONSOLE_UI_OPTS = $(conlflags) $(conlibsdll)
CPU=amd64
COMPILE_OPTS = $(INCLUDES) $(cdebug) $(cflags) $(cvarsdll) -I. /EHsc /O2 /MD /GS /D "WIN64" /Oy- /Oi /D "NDEBUG"
C = c
C_COMPILER = cl
C_FLAGS = $(COMPILE_OPTS)
CPP = cpp
CPLUSPLUS_COMPILER = $(C_COMPILER)
CPLUSPLUS_FLAGS = $(COMPILE_OPTS)
OBJ = obj
LINK = link -out:
LIBRARY_LINK = lib -out:
LINK_OPTS_0 = $(linkdebug) ws2_32.lib /NXCOMPAT
LIBRARY_LINK_OPTS =
LINK_OPTS = $(LINK_OPTS_0) $(UI_OPTS)
CONSOLE_LINK_OPTS = $(LINK_OPTS_0) $(CONSOLE_UI_OPTS)
SERVICE_LINK_OPTS = kernel32.lib advapi32.lib shell32.lib ws2_32.lib -subsystem:console,$(APPVER)
LIB_SUFFIX = lib
LIBS_FOR_CONSOLE_APPLICATION =
LIBS_FOR_GUI_APPLICATION =
MULTIMEDIA_LIBS = winmm.lib
EXE = .exe
PLATFORM = Windows
rc32 = rc.exe
.rc.res:
$(rc32) $<
After you've edited this file, run the genWindowsMakefiles command from bash (or the CMD file). Next, start the x64 Visual Studio Command Prompt. Make sure you got the x64 native configuration flavor of it. Issue the following commands:
cd c:\projects\live\liveMedia
nmake -f liveMedia.mak
cd ..\groupsock
nmake -f groupsock.mak
cd ..\UsageEnvironment
nmake -f UsageEnvironment.mak
cd ..\BasicUsageEnvironment
nmake -f BasicUsageEnvironment.mak
cd ..\testProgs
nmake -f testProgs.mak
cd ..\mediaServer
nmake -f mediaServer.mak
Alter the first command to match the directory where you put the source.
TODO items: cleaning doesn't work, it tries to use the *nix rf command. Simplest workaround is del *.obj to force the compiler to rebuild the object files
the .exe files are built without a manifest. Shouldn't matter for the test programs, I assume you're only interested in the .lib files
it builds the release version of the libraries and executables, you'll have to tweak the COMPILE_OPTS to get a debug build.
In order to compile 64 bit native code with Visual Studio 2013, you
require professional edition.
Open the VS2013 x64 Native Tools Command Prompt
Then make sure you set C_COMPILER to "$(TOOLS32)\bin\amd64\cl" after correcting TOOLS32 to the VC/bin dir.
In order to compile 64 bit native code with Visual Studio 2013, you require professional edition.
Open the VS2013 x64 Native Tools Command Prompt
Then make sure you set C_COMPILER to "$(TOOLS32)\bin\amd64\cl" after correcting TOOLS32 to the VC/bin dir.
I'm using win7-32bit + cmake + vs2013's NMake.exe to build exe, I need the exe be able to run on WinXP, I know how to do that with vs2013 IDE(set the Platform-Toolset to v120xp), but I'm not using the IDE, I just use its NMake. This is how I generate the project file and exe:
build> cmake -G "NMake Makefiles" ..
build> nmake
Question 1: In the CMakeLists.txt, how to set it use v120xp?
Question 2: Is it necessary to build all static lib with the v120xp? Or just the exe?
Try setting CMAKE_GENERATOR_TOOLSET. It allows selecting the toolset for Genertors that support it. Generators that support Toolsets are Visual Studio and XCode.
Your call to CMake should look like this:
cmake -G "NMake Makefiles" -DCMAKE_GENERATOR_TOOLSET=v120_xp ..
Update 1: As pointed out in the comments NMake doesn't support Toolsets
Thes solution is to specify
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /SUBSYSTEM:CONSOLE,5.01")
for console applications, or
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /SUBSYSTEM:WINDOWS,5.01")
for windows applications.