Developer Tools

How to edit and test application code in CodeReady Workspaces

How to edit and test application code in CodeReady Workspaces

In this CodeReady Workspaces video, learn how to create a new workspace using the code generated from the launcher, and how to make the application run locally. Also find out how to build and deploy an application locally within the workspace, how to edit and test the code, and how to commit code changes to a remote git repository. The steps described in this video are also available in the tutorial on GitHub.

Continue reading “How to edit and test application code in CodeReady Workspaces”

Share
Getting started with CodeReady Workspaces and Red Hat OpenShift Application Runtimes launcher

Getting started with CodeReady Workspaces and Red Hat OpenShift Application Runtimes launcher

Watch this video for an introduction to CodeReady Workspaces and Red Hat OpenShift Application Runtimes, their functionality, and how they complement each other for cloud-native application development on OpenShift. This is the first part of a video series, and the subsequent videos will cover step-by-step instructions to use Launcher and CodeReady workspaces. To try hands-on labs, refer to the tutorial on GitHub.

Continue reading “Getting started with CodeReady Workspaces and Red Hat OpenShift Application Runtimes launcher”

Share
RPM packaging: A simplified guide to creating your first RPM

RPM packaging: A simplified guide to creating your first RPM

The concept of RPM packaging can be overwhelming for first-timers because of the impression a steep learning curve is involved. In this article, I will demonstrate that building an RPM with minimal knowledge and experience is possible. Note that this article is meant as a starting point, not a complete guide to RPM packaging.

Continue reading “RPM packaging: A simplified guide to creating your first RPM”

Share
Understanding GCC warnings, Part 2

Understanding GCC warnings, Part 2

In part 1, I shed light on trade-offs involved in the GCC implementation choices for various types of front-end warnings, such as preprocessor warnings, lexical warnings, type-safety warnings, and other warnings.

As useful as front-end warnings are, those based on the flow of control or data through the program have rather inconvenient limitations. To overcome them, flow-based warnings have increasingly been implemented in what GCC calls the “middle end.” Middle-end warnings are the focus of this article.

Continue reading “Understanding GCC warnings, Part 2”

Share
Understanding GCC warnings

Understanding GCC warnings

Most of us appreciate when our compiler lets us know we made a mistake. Finding coding errors early lets us correct them before they embarrass us in a code review or, worse, turn into bugs that impact our customers. Besides the compulsory errors, many projects enable additional diagnostics by using the -Wall and -Wextra command-line options. For this reason, some projects even turn them into errors via -Werror as their first line of defense. But not every instance of a warning necessarily means the code is buggy. Conversely, the absence of warnings for a piece of code is no guarantee that there are no bugs lurking in it.

In this article, I would like to shed more light on trade-offs involved in the GCC implementation choices. Besides illuminating underlying issues for GCC contributors interested in implementing new warnings or improving existing ones, I hope it will help calibrate expectations for GCC users about what kinds of problems can be expected to be detected and with what efficacy. Having a better understanding of the challenges should also reduce the frustration the limitations of the available solutions can sometimes cause. (See part 2 to learn more about middle-end warnings.)

The article isn’t specific to any GCC version, but some command-line options it refers to are more recent than others. Most are in GCC 4 that ships with Red Hat Enterprise Linux (RHEL), but some are as recent as GCC 7. The output of the compiler shown in the examples may vary between GCC versions. See How to install GCC 8 on RHEL if you’d like to use the latest GCC.

Continue reading “Understanding GCC warnings”

Share
An overview of Eclipse Che

An overview of Eclipse Che

This video is a brief overview of Eclipse Che presented by CodeReady Workspaces Product Manager Stévan Le Meur. The tour starts in a git repo that contains a link to a Che factory. Opening that factory loads the code from the git repo and sets up a complete development environment. From there, Stévan covers how to build, run, and debug the code within Che.

Continue reading An overview of Eclipse Che

Share
Changes made to the Libabigail ABI change analysis framework in 2018

Changes made to the Libabigail ABI change analysis framework in 2018

This article is for people interested in the long-term maintenance of software systems that expose application binary interfaces (a.k.a. ABIs) to other systems. That long-term maintenance involves detecting and analyzing inevitable changes in the ABIs and assessing whether these changes allow the maintained systems to stay compatible with the components with which they interact.

In this article, I describe what happened to the ABI change analysis framework that I worked on during 2018: the Abigail library (Libabigail) and its associated set of tools. The goal is not to list the myriad changes that happened throughout releases 1.2, 1.3, 1.4, and 1.5 that occurred during that year, but I will walk you through the main changes that happened and put them in perspective.

Continue reading “Changes made to the Libabigail ABI change analysis framework in 2018”

Share
How to install GCC 8 and Clang/LLVM 6 on Red Hat Enterprise Linux 7

How to install GCC 8 and Clang/LLVM 6 on Red Hat Enterprise Linux 7

There has been a lot of work to improve C/C++ compilers in recent years. A number of articles have been posted by Red Hat engineers working on the compilers themselves covering usability improvements, features to detect possible bugs, and security issues in your code.

Red Hat Enterprise Linux 8 Beta ships with GCC 8 as the default compiler. This article shows you how to install GCC 8 as well as Clang/LLVM 6 on Red Hat Enterprise Linux 7. You’ll be able to use the same updated (and supported) compilers from Red Hat on both RHEL 7 and 8.

If you want your default gcc to always be GCC 8, or you want clang to always be in your path, this article shows how to permanently enable a software collection by adding it to the profile (dot files) for your user account. A number of common questions about software collections are also answered.

Continue reading “How to install GCC 8 and Clang/LLVM 6 on Red Hat Enterprise Linux 7”

Share