Due to the lack of compiler support for inline assembler with 64 bit targets, I have need to build it in separate files.
I have VS 2010 Professional, how can I set this up?
I would recommend using yasm via its very own vs integration mechanisms.
Basically, it comes down to installing an extra tool as an assembler in the VS settings files etc; however, the YASM team have done it for you which is incredibly useful.
Related
before I explain my current problem with Visual Studio in combination with CMake, I try to explain what I want to accomplish as there might be a better solution.
At our company we have a huge code base mainly written in C for QNX. For development we are using the standard IDE QNX momentics. As this is based on a quite old eclipse version ... the whole IDE sucks.
I'm currently evaluating to use Visual Studio as a replacement. With a really simple HelloWorld-programm I was able to build and debug the project from within VS using CMake and a CMakeSettings.json.
As our code base is basically organized in a tree-like structure, I've created a typical hierarchy of CMakeLists.txt which allows me to build single/multiple projects.
As QNX delivers its own compiler I've created a toolchain file, this is running fine so far, the required toolchain is invoked once a build is triggered via cmake.
Now for the part that I'm struggling with:
How to use this CMake setup in order to develop/debug code from VS?
I had two ideas in mind which don't really work or I'm doing something wrong.
Use the CMake generator for VS 2019 and generate a complete solution. Problem: The toolchain file is not "used" as all projects will be setup with the internal VS compilers. Is there any way to get this working? I thought calling cmake -G "Visual Studio 16 2019" -DCMAKE_TOOLCHAIN_FILE=$FILE would do the job. Additionally: how would I incorporate the debugger configuration? With this solution the CMakeSettings.json seems to be ignored as VS solutions are used.
Use File->Open->CMake to open the root project. Shouldn't this show all "contained" projects which also include a CMakeLists.txt as projects? I can only see the folder tree in the Solution Explorer. Build a single project from the solution explorer is also not possible ... there is simply no option.
Anyone with experience on this topic?
Minor comment please limit questions to 1 question in the future. Multiple questions clutters questions and makes search results worse.
============================================================
I'll answer question #1 this part of question number 1.
"Use the CMake generator for VS 2019 and generate a complete solution. Problem: The toolchain file is not "used" as all projects will be setup with the internal VS compilers. Is there any way to get this working? I thought calling cmake -G "Visual Studio 16 2019" -DCMAKE_TOOLCHAIN_FILE=$FILE would do the job."
Instead of using Visual Studio as your generator try using "Ninja" instead. Ninja will work if your toolchain code is correct. Toolchains and visual studio are complicated to say the least. If you wanna go down that rabbit hole I can help but that's a separate question
Basically try switching to Ninja instead of Visual Studio as your generator for CMakeSettings.json. Ninja is very easy to write toolchains for.
======================================================================
"Additionally: how would I incorporate the debugger configuration?"
The MSDN articles are actually quite good. I figured it out this week. In my opinion the debugger configurations are more powerful with the CMake approach than vanilla visual studio.
Configure CMake debugging sessions
https://learn.microsoft.com/en-us/cpp/build/configure-cmake-debugging-sessions?view=msvc-160
"Tutorial: Debug a CMake project on a remote Windows machine"
https://learn.microsoft.com/en-us/cpp/build/cmake-remote-debugging?view=msvc-160
Trust me once it clicks you'll love it.
Visual Studio 2017 RC includes much tighter CMake integration, allowing one to skip the intermediate step of generating project/solution files and use CMake effectively as the project file itself. There is sufficient documentation from Microsoft for using these features with regular C++ files, and there is sufficient documentation on this website (example) for making CUDA and Cmake play nicely, when it comes to linking CUDA code to C++ code.
What I can't find information on is how to make CMake, Visual Studio 2017 RC, and CUDA 8.0 all play nicely. This is a difficult problem, because 2017RC has no integration for the CUDA SDK anyways, and I was hoping to use 2017RC so that my C++ interface to the CUDA code could use C++14 and/or C++17. I'm working on the beginning of a large project that will primarily involve writing a static CUDA library that is accessed through C++: so, I'd like to get the CMake to take care of compiling my CUDA sources into a static library, and for it to help with feeding the linking information to Visual Studio. So far, I haven't had any success with using FindCUDA's various features to accomplish this, but I'm assuming that's due to a misunderstanding on my part. I've read through the documentation on separable compilation from Nvidia, but that wasn't helpful for figuring out CMake.
Further, whenever I try to use CMake in VS2017RC, I still end up with the various vcxproj files that CMake likes to spit out. Is this due to an error on my part? How do I edit the build command arguments, or CMakeLists.txt, to get the functionality demonstrated here to work?
The very short (and only at the time of writing) answer is that you can't. CUDA 8 doesn't support VS2017. Only VS2015 is presently supported.
You can always find the compiler/IDE versions which the release version of CUDA supports here
Edit to add that the CUDA 9 release will add official support for VS2017.
All you need to do is set the CUDA_HOST_COMPILER variable to a supported compiler for example the visual studio 2015 compiler.
In my case this is:
C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe
As both runtime libraries are binary compatible you can use the 2015 compiler within CUDA and compile all the rest of the application with the 2017 compiler.
Is there some kind of plugin, extension or something that would enable 64-bit inline assembly in Microsoft Visual Studio 2010?
From http://msdn.microsoft.com/de-de/library/4ks26t93%28v=vs.100%29.aspx
Programs with inline assembler code are not fully portable to other
hardware platforms. If you are designing for portability, avoid using
inline assembler.
Inline assembly is not supported on the ARM and x64 processors.
Not that I know of, but you don't really need it - you can simply assemble the assembly code separately and link it in. You don't even need a plugin for that, just right click the project, go to build customizations, and enable masm. Then you just add some assembly files.
If you don't really like masm with its "dword ptr" and strange semantics for variables and so on, you can use yasm plugin (which is enabled in the same way, except you enable yasm in the build customizations instead of masm).
I am creating a very large project (a few thousand lines) and so would rather not use Notepad++. An IDE would make it so much easier. I have experience with Microsoft Visual Studio and love it. Is there some easy way to use Cygwin's GCC from within Microsoft Visual Studio?
Alternately, are there any other good Windows IDEs for GCC besides NetBeans and Eclipse? (I hate both of them with a passion.)
There are several ways to go here:
Option 1: Create a Custom Build Tool
Visual Studio 2005 and newer will let you register custom build tools. They tell the IDE how to transform files of one form (e.g. a .cpp file) into another form (e.g. an .obj file).
So far as I know, no one has done this yet for GCC. And, doing it yourself requires writing COM code, which is probably too deep a pool to dive into just for a single project. You'd have to have a compelling reason to take this project on.
You then have to manually adjust each project to tell it to use the custom build tool instead of the default, since you're using a file name extension (.cpp, probably) that Visual C++ already knows about. You'll run into trouble if you try to mix the VC++ and g++ compilers for a single executable built from multiple modules.
On the plus side, if you were looking to start an open source project, this sounds like a good one to me. I expect you'd quickly gather a big user base.
Option 2: Makefile Project
Start Visual Studio and say File > New Project.
In the Visual C++ section, select Makefile Project
Fill out the Makefile Project Wizard:
Build command line: make
Clean commands: make clean
Rebuild command line: make clean all
You can leave the Output (for debugging) field alone if you've named your executable after the project name and it lands where Visual Studio expects to find it.
Leave the rest of the fields alone unless you know what they are and why you want to change them. As an example, you might choose to pass a -D flag on the Preprocessor definitions line to get separate debug and release outputs. If you know you want this, you know how to set it up, so I'm not going to make this long answer even longer in order to explain it.
You'll be asked the same set of questions for the Release build. If you want to bother with separate debug and release builds, you'd make any changes here.
Having done all this, you still have to create the Makefile, and add a make.exe to your PATH. As with the debug vs. release question, going into that level of detail would push this answer off topic.
As ugly as this looks, it's still easier than creating custom build tools. Plus, you say you need to port to Unix eventually, so you're going to need that Makefile anyway.
Option 3: Cross-Platform Development
You say you want to port this program to Unix at some point, but that doesn't mean you must use GCC on Windows now. It is quite possible to write your program so that it builds under Visual C++ on Windows and GCC/Makefiles on *ix systems.
There are several tools that make this easier. One very popular option is CMake, which is available as an installation time option in newer versions of Visual Studio. There are many alternatives such as SCons and Bakefile.
Clang
You can use the Clang compiler with Visual Studio to target Android, iOS, and Windows.
If you are targeting Android, you can use the Clang/LLVM compiler that ships with the Android NDK and toolchain to build your project. Likewise, Visual Studio can use Clang running on a Mac to build projects targeting iOS. Support for Android and iOS is included in the “Mobile Development with C++” workload. For more information about targeting Android or iOS check out our posts tagged with the keywords “Android” and “iOS”.
If you are targeting Windows, you have a few options:
Use Clang/LLVM; “Clang for Windows” includes instructions to install Clang/LLVM as a platform toolset in Visual Studio.
Use Clang to target Windows with Clang/C2 (Clang frontend with Microsoft Code Generation).
GCC
If your project targets Linux or Android, you can consider using GCC. Visual Studio’s C++ Android development natively supports building your projects with the GCC that ships with the Android NDK, just like it does for Clang. You can also target Linux – either remotely or locally with the Windows Subsystem for Linux – with GCC.
Check out our post on Visual C++ for Linux Development for much more info about how to use Visual Studio to target Linux with GCC. If you are specifically interested in targeting WSL locally, check out Targeting WSL from Visual Studio.
Source: https://devblogs.microsoft.com/cppblog/use-any-c-compiler-with-visual-studio/
I'm from the future.
I keep (poking at) a C/C++ toolchain using Visual Code on Win/Lin/Mac and MinGW installed from Choclatey.
(This was done for my sanity - install GDB and GCC however you want)
I've run it with GCC and GDB with IntelliSense using MS's own weird JSON makefiles.
Someday, someone (you?) will write a Gradle or Python script to generate these; for now the examples online in the docs seem to work.
It seems to require three types of JSON thing;
a single IntelliSense configuration for the whole workspace
a Debugging Configuration entry for each binary you want to debug
these can invoke the build tasks
a Build Task per-artifact
I don't think that there's a "require" or "dependency" thingie-mah-bob; sorry
The requirements listed in the 3ds Max SDK state that plug-ins for 3ds Max 2011 must be built with Visual C++ 9.0 (Visual Studio 2008).
If I create a DLL with a different version of Visual C++, won't the binary be identical? Is this simply a matter of choosing the right compiler settings?
What problems will I run into if I try to build a plug-in using Visual C++ 2010 (Visual Studio 2010)?
I don't know specifically for 3ds Max, but the usual reason is the C Runtime library. If the host application uses the DLL version of the CRT, then plugins will also need to use the same version.
Otherwise, imagine the case where your plugin creates some memory using malloc(), and passes it to the host application, which uses it and then calls free(). If your plugin and the host application are using different CRTs, the host's call to free() will fail or crash because it wasn't the host's CRT that malloc()ed that block of memory.
The binary won't be identical but the binary interfaces should be, which is what you need.
The reason you can't use VS2010 is because it is not yet production quality. They think you should wait for VS2010 SP1 at a minimum.
You think they are just being obstinate and stubborn, eh? Ruining all your fun. They have reasons. Good ones.
Because of bugs like this:
https://connect.microsoft.com/VisualStudio/feedback/details/565959
I use both visual studio 2008 and 2010 for plugin development.
Only difference I've seen is that the user need the vs c++ runtime version for 2010\2008.
But there might be pitfalls - but I have not encountered any problems with it yet.
C++ doesn't have a standardised binary interface. The compiler "mangles" each symbol name (i.e. each function or static data) to include information about namespaces and signature, so that namespaces, argument overloading, &c. can work. Each compiler is free to decide how to do this. Different MSVS compiler versions do name mangling in different ways, so in general you can't link a C++ library compiled with 2005 and a library compiled with 2008 together: this includes loading a 2008 DLL from a 2005 executable (for example). You can do this if the interface between the libraries is C, as long as the relevant functions are marked with extern "C" to prevent name mangling. And in practice the differences are not always that great: for example, I never had trouble using VS2005 SP1 to compile a library for 3ds Max 9, which supposedly requires VS2005 with no service pack.
Microsoft is trying to fix this incompatibility, so in VS2010 they introduced an option, so VS2010 can produce binaries compatible with VS2005 programs or VS2008 programs (maybe some earlier versions too, I forget). If you have to create a plugin to work with multiple 3ds Max versions, and you don't get caught out by any VS2010 bugs, this is probably a good option. Also, the Intel C++ compiler has a mode where it produces binaries that are compatible with an MSVS version of your choice, which might be a better option for you if it's for hobby use or you can afford the slightly expensive price tag. (They achieve this by copying the way MSVS does name mangling.)