Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Reuther Newsgroups: comp.arch.embedded Subject: Re: Makefile or IDE? Date: Sun, 5 Dec 2021 11:02:12 +0100 Lines: 38 Message-ID: References: <7ugnqgpgu34hb8gvhsglse4e49dj5anhjd@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: individual.net iqDFVg05JpTg0cDvrW8o/QV/zYkWCJqgRtqzvJ0FpOpMQUg8Vz Cancel-Lock: sha1:mTG8AGBYoFqhxV501z0YbcGp9fc= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 Hamster/2.1.0.1538 In-Reply-To: Xref: csiph.com comp.arch.embedded:30945 Am 04.12.2021 um 22:17 schrieb David Brown: > On 04/12/2021 20:53, George Neuner wrote: >> On Fri, 3 Dec 2021 21:28:54 -0000 (UTC), Grant Edwards >>> I always had good luck using Cygwin and gnu "make" on Windows to run >>> various Win32 .exe command line compilers (e.g. IAR). I (thankfully) >>> haven't needed to do that for several years now... >> >> The problem with Cygwin is it doesn't play well with native Windows >> GCC (MingW et al). [...] > I concur with that. Cygwin made sense long ago, but for the past couple > of decades the mingw-based alternatives have been more appropriate for > most uses of *nix stuff on Windows. In particular, Cygwin is a thick > compatibility layer that has its own filesystem, process management, and > other features to fill in the gaps where Windows doesn't fulfil the > POSIX standards (or does so in a way that plays badly with the rest of > Windows). The problem is that both projects, Cygwin and MinGW/MSYS, provide much more than just a compiler, and in an incompatible way, which is probably incompatible with what your toolchain does, and incompatible with what Visual Studio does. "-Ic:\test" specifies one path name for Windows, but probably two for a toolchain with Unix heritage, where ":" is the separator, not a drive letter. Cygwin wants "-I/cygdrive/c" instead, (some versions of) MinGW want "-I/c". That, on the other hand, might be an option "-I" followed by an option "/c" for a toolchain with Windows heritage. The problem domain is complex, therefore solutions need to be complex. That aside, I found staying within one universe ("use all from Cygwin", "use all from MinGW") to work pretty well; when having to call into another universe (e.g. native Win32), be careful to not use, for example, any absolute paths. Stefan