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.
Related
I am attempting to make a simple ToolChain for the Borland 4.5 compiler with the Pharlap extender based on instructions at the Apache website: https://netbeans.apache.org/kb/docs/cnd/toolchain.html
I am basing the ToolChain on MinGW so that I can use those tools for make.
I cannot get the new toolset to find the Borland compilers the way MinGW is automatically discovered. If I use g++ as the compiler name, Netbeans finds that OK. The issue seems to be with the directory. I'm assuming an installation directory of C:\BC45\BIN and attempting to find BCC32.EXE in that directory.
When I run (clean, build, then run) the test installation of the netbeans module, I see my new toolchain in C/C++, but the field for the C++ compiler is always empty unless I specify a program in the c:\mingw\bin (base) directory.
I have tried variations on the following in my cpp xml file, making sure from time to time that it works just fine with g++ as the name:
<cpp>
<compiler name="bcc32.exe"/>
<recognizer pattern=".*[\\/]bc45.*[\\/]bin[\\/]?$"/>
I haven't found documents beyond the Apache website. I'm basing my guesses on what I have found in: %appdata%\NetBeans\12.4\config\CND\ToolChain\MinGW.xml
The XML above was OK as far as it goes. The example at apache.org only fills in the subclass of c++ (cpp). When I also subclassed the c, assembler, and linker, I ended up with the fields in the C++ options automatically populating as expected.
vcc4n (https://sourceforge.net/p/vcc4n/wiki/Home/) has a good example of implementing the four important classes for those build tools, but really just continuing the example to create and fill in the additional XML as specified in layer.xml is straightforward enough.
Is there a way or steps to follow to integrate a yocto SDK (standard or extensible) with VSCode? I want to cross-compile, remote connect, and debug a C/C++ application within VSCode for target hardware using a yocto generated Linux image. Is this possible? I know of the bitbake extension but couldn't find one for the SDK. Thank you!
Conservatively, I would say it depends on the level of integration you want to achieve but I use regularly VS Code to edit and build, sometime to debug C applications using a Yocto toolchain, that's really easy for Makefile projects for example.
Assuming you do not ask for Yocto integration into VS Code (I don't know if something exists) but really to use the tools generated by the SDK from Yocto and that you already are familiar with Yocto toolchain usage.
I personally compile on Linux server remotely from a Windows PC. The server contains therefore my projects and the Yocto toolchain.
I use for that the nice Remote SSH extension from Microsoft on VS Code. From there, I can edit easily the files, compile and a terminal is available (that's out of the scope of your question however).
So if working as me or directly in Linux, you can create a Makefile/CMake project for example. The C/C++ VS Code extension is a must have.
Each time you start working, you source the Yocto SDK toolchain and compile directly using make from the terminal window of VSCode. If you want to automatize the build step, you can use the task feature of VS which allows you to launch build script for example.
Regarding the remote connect, the terminal window of VS can also have multiple sub-windows with various connections like SSH to the target. The build script can also use scp to send the generated binary directly to the target but your question is vague regarding what you want to do.
Finally for the debug aspect, GDB is well supported in VS Code and the official doc is a good start as well as the C++ debugging doc.
On the Yocto side, you need to add gdbserver to the image running on the target, it can be done by adding the following to your conf/local.conf:
EXTRA_IMAGE_FEATURES += "tools-debug"
If you want to have debug information for the shared libs on the target, you also need to add:
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
Finally, the SDK must be generated with the same options as the image running on the target and will contain the cross-gdb tool like -gdb to be used on the host side.
So that's possible but requires some setup especially the debug part. As far as I know, there is not a VS Code extension managing all these steps for you automagically.
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 want to build a program ("exe" or "static lib") using ECL, but under windows. My application must depend on "ecl.dll".
How to modify the MSVC makefile to build ECL statically?
As I explained in the mailing list, ECL's Makefile for Microsoft's compilers currently does not have this option. It simply hasn't been ported from their siblings that run on Unix-type environments. But that does not mean it cannot be done.
I want to create 64 bit apps for (for example) 64 bit Windows 7. I've searched the web and found some help but couldn't get it to work.
Sorry I've taken so long to respond but I have tried to get the packages suggested to work but they're not easy or else I'm doing something wrong.
Anyway I ran across an environment called pellesc. It consists of a development environment around a compiler which traces is roots back to a 32-bit version that was once (according to Wikipedia) used to develop Quake. From what I've seen so far it's very promising and generates good code too!
In spite of what other people are saying, Eclipse actually has very good support for C++, even in Windows: check out the CDT project. It's very mature and well-supported -- it works for C/C++ at least as well as Eclipse JDT works for Java.
As for the compiler itself, VonC is right, MinGW-w64 (but the mingw-w64 project is moving to mingw-w64.org so i suggest to use mingw-w64.org) is the best option. Eclipse CDT has built-in support for MinGW so as long as you install MinGW first, Eclipse should automatically detect it.
This Eclipse MinGW64 tutorial mentions:
update (Nov 9, 2010): recent MinGW-w64 versions come with 'as', 'g++', and 'gcc' commands. This step may be unnecessary in your MinGW build.
Meaning you won't have anymore to update the GCC assembler, C++ compiler, C compiler and C++ linker, with 'x86_64-w64-mingw32-as', 'x86_64-w64-mingw32-g++', 'x86_64-w64-mingw32-gcc', and 'x86_64-w64-mingw32-g++'.
Other great source for w64 development tools:
Native windows x64 software develop with Mingw-w64 on drangon.org
A 64-bit version of GCC for Windows is available at http://tdm-gcc.tdragon.net/download. I can't see why you would want to use Eclipse for C or C++ programming - try the Code::Blocks IDE at http://www.codeblocks.org instead.
Honestly, I use cygwin. Its compatable with unix so you can easily move systems and has tons of functionality that is gcc friendly (autoconf, make, makedepends, ...). To use gcc to compile to 64 bit add the -m64 option. To compile for windows use the -mno-cygwin option. Make sure though that you're using gcc 3 and not 4 (then you'd use the mingw compiler series). Otherwise, its all the same as unix which is really useful.