From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id EEE421B3B8 for ; Tue, 8 Jan 2019 15:10:43 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 4CE684002A for ; Tue, 8 Jan 2019 15:10:43 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 3D3D140028; Tue, 8 Jan 2019 15:10:43 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.1 X-Spam-Score: -0.9 Received: from [192.168.1.59] (host-90-232-172-103.mobileonline.telia.com [90.232.172.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 02BD940027; Tue, 8 Jan 2019 15:10:39 +0100 (CET) To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , Bruce Richardson , Stephen Hemminger Cc: "Burakov, Anatoly" , Thomas Monjalon , Jason Messer , Harini Ramakrishnan , Omar Cardona , Ranjit Menon , Jeff Shaw , dev@dpdk.org References: <7824863.MkUOD0j12R@xps> <005401d4a32e$2f20f860$8d62e920$@networkplumber.org> <20190107075138.654e0be5@hermes.lan> <20190107161534.GA15532@bricha3-MOBL.ger.corp.intel.com> <4ca4ff83-d226-12c4-913c-22737dfc5bb6@intel.com> <20190107085125.3e3adf05@hermes.lan> <20190107170021.GB23828@bricha3-MOBL.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC35B425AE@smartserver.smartshare.dk> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: Date: Tue, 8 Jan 2019 15:10:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B425AE@smartserver.smartshare.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] Compiler for Windows X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 14:10:44 -0000 On 2019-01-08 13:51, Morten Brørup wrote: >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson >> I think for windows we probably want to start with the MS compiler >> first, >> since from my understanding it's probably the default go-to compiler >> for >> developers on windows, and look at alternatives from there. >> >> /Bruce > > Having developed quite a bit in Windows myself (about a decade ago), I tend to agree with Bruce here. However, I would add that it depends on who we are targeting: > > If we are targeting typical Windows developers (of all levels of experience), it's my impression that Microsoft's compiler IDE, Visual Studio (or Visual Studio Code), is their tool of choice, and anything else would introduce a learning curve. (This is probably more true for junior developers than senior developers, who often have worked in a range of different development environments.) > Visual Studio supports clang, and regardless, maximizing the *convenience* for a few Windows developers shouldn't really be a priority. Let's be real; Windows is very likely to remain a minor player in the domain of operating systems for network processing. Just to be clear, I'm not saying we should sabotage a Windows port. What I am voting against, is to allow a Windows port to sabotage the DPDK source code, and prevent the use of useful compiler features, messing up the code in the process. As for junior developers, if they are going to program in DPDK, installing a compiler is such a minor part of the learning curve ahead, they won't notice the tiny bit of extra climb. > If we are targeting developers who want to make their applications compatible across multiple operating systems, any compiler would probably work just fine - and in this case, the real question is about making the "make" environment as cross-platform compatible as possible. > The discussion has been about compilers, not any build system or tools. > Maybe you can get inspiration by looking at other cross-platform projects... Google Chrome, Mozilla Firefox, Wireshark, etc. > As mentioned in this thread already, Chromium relies on clang.