Skip to main content

Eric Melski

Member for

13 years 3 months

Eric is Chief Architect for ElectricAccelerator, a high-performance implementation of make from Electric Cloud, Inc.  He obtained a BS in Computer Science from the University of Wisconsin in Madison in 1999.  In 2002 Eric co-founded Electric Cloud, where he has spent more than a decade developing distributed, parallel systems designed to accelerate build processes.  He is named on seven patents related to his work on build acceleration at Electric Cloud.

Company
Electric Cloud, Inc.
Job Function
Development
Job Title
Chief Architect
Industry
Computer Software - SaaS
Interests
Agile
Architecture
Cloud
Design
Development Lifecycles
Embedded Systems
Open Source
Performance Testing
Programming
Quality Assurance
Requirements
Test Automation
Country
United States

Eric is Chief Architect for ElectricAccelerator, a high-performance implementation of make from Electric Cloud, Inc.  He obtained a BS in Computer Science from the University of Wisconsin in Madison in 1999.  In 2002 Eric co-founded Electric Cloud, where he has spent more than a decade developing distributed, parallel systems designed to accelerate build processes.  He is named on seven patents related to his work on build acceleration at Electric Cloud.

All Articles by Eric Melski


All Stories by Eric Melski

Descrambling Parallel Build LogsOne of GNU make's many features allows you to shorten build times by running more than one command at a time. If your dependencies are all correct, or nearly correct, this can give you a significant improvement, and since it's built into the tool you get it "for free." But GNU make's parallel build feature—often called "dash j mode," after the command-line option that is used to enable it—is not without drawbacks. The worst of these is that GNU make parallel builds can produce incorrect results if the build dependencies are not sufficiently correct.
Rules With Multiple Outputs in GNU MakeOne problem that Makefile writers sometimes have is the need to write a single rule that produces multiple output files in order to accommodate tools that don't fit the standard one-command-one-output model generally assumed by Make. Eric Melski takes a look at a few alternatives, including the one and only way to truly capture the relationship in GNU Make syntax.