thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gonzalo Aguilar (JIRA)" <>
Subject [jira] [Commented] (THRIFT-4037) [CMake] As a developer, I want to use a single build system for thrift to make development easier
Date Fri, 10 Feb 2017 14:21:41 GMT


Gonzalo Aguilar commented on THRIFT-4037:

I understand that all move is to support Windows because the proper lack of tools to build...

> [CMake] As a developer, I want to use a single build system for thrift to make development
> -------------------------------------------------------------------------------------------------
>                 Key: THRIFT-4037
>                 URL:
>             Project: Thrift
>          Issue Type: Epic
>          Components: Build Process
>    Affects Versions: 0.10.0
>         Environment: All
>            Reporter: James E. King, III
>            Assignee: James E. King, III
>            Priority: Critical
> h1. Background
> The thrift project currently carries two build systems.  The original build system is
based on autoconf and is used to build a complete deliverable including extensive cross-language
> The other build system was introduced a few years ago, with roots tracing back to THRIFT-797.
 CMake allows thrift to build natively on multiple platforms - unix and windows.  Autoconf
is no longer under active development with the last release in 2012, and it does not allow
for native windows builds using native tools that are used by a majority of consumers.
> Maintaining two build systems for a project incurs a lot of overhead.  Every change that
touches the build system needs to be done twice, in two completely different ways.  We need
twice as many CI jobs to verify that all of the builds are working, whereas with a single
cmake build environment we could likely use a single CI build job per platform that does everything
using the docker image on linux and appveyor on windows.
> h1. Proposal
> We should officially deprecate autoconf in favor of cmake, and continue (more aggressively)
the effort to make the cmake build environment as functional as the autoconf build environment.
 During this transition, folks will be required to make changes to both build systems (which
are proven out mostly through the Travis CI build jobs; only CMake is used on AppVeyor).
> h1. Acceptance Criteria
> # autoconf build environment is removed

This message was sent by Atlassian JIRA

View raw message