Alternatives to Visual Studio as a requirement for gyp?

[Andrew Pennebaker]

In terms of low level build tools, gyp needs make and a C compiler. In Unix, this typically means make and gcc, through some sort of build-essential package. In Windows, this traditionally means nmake and cl, through Visual Studio or the free VS Express. But modern make/gcc environments are now available for Windows, and it would be helpful for gyp users if gyp recognized them as an option.

In addition to Visual Studio, Unix-style build tools are available through

* Cygwin (make and gcc)

* MinGW (make and gcc)

* Strawberry Perl (gcc)

Could gyp become more flexible in Windows environments, using these instead of Visual Studio?

[Ryan Sleevi]

So GYP acts as a meta-build system, and in the original design,
generators were cross-platform. That is, that you should be able to
generate make files from Windows or Visual Studio solutions from
Linux.

Over time, I suspect that this has regressed and is no longer true,
but that was the original design.

As far as supporting GCC itself as a compiler on Windows, nothing
(should) prevent you from being able to use the Makefile generator on
Windows and emit makefiles that use CC/CXX on Win. Have you tried?

Note that GYP does support, on Windows, an alternative generator
called Ninja ( https://github.com/martine/ninja ), which is much more
efficient than Make. While the current Ninja-on-Windows (nicknamed
"winja") generator makes assumptions that the compiler is MSVC, it
should also be possible to have it generator ninja files that work
with gcc.

[Ryan Sleevi]

On Tue, Feb 12, 2013 at 1:16 PM, Andrew Pennebaker
<andrew.p...@gmail.com> wrote:
> More specifically, node-gyp claims that Visual Studio is required, when in
> fact any provider of make and a C compiler will do.
>
> If you could document that gyp works with MinGW, Cygwin, etc, then node-gyp
> should be able to reflect this downstream. They're claiming the dependency
> is upstream in gyp, when in fact no such dependency exists.

I'm not familiar with node-gyp, but it's entirely reasonable that they
structured their GYP files to only work with Visual Studio.

That's not a requirement of GYP, but not at all unheard of for large
GYP projects. For example, Chromium's GYP files do the same thing
(that is, effectively requiring MSVC)

[Dirk Pranke]

On Tue, Feb 12, 2013 at 1:01 PM, Andrew Pennebaker
<andrew.p...@gmail.com> wrote:

Ryan's already addressed this pretty well, but I would reiterate that
there's no inherent reason gyp doesn't support other windows build
tools and chains better. I would think such patches would be welcome.

I would also note that the current code base (at least the last time I
looked, which is pre-ninja-everywhere) doesn't do a great job of
separating build tool code from toolchain code so that it's easier to
reuse the logic for talking to particular compilers across different
build tools, but maybe things have gotten better.

-- Dirk

[Evan Martin]

On Tue, Feb 12, 2013 at 1:12 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

So GYP acts as a meta-build system, and in the original design,

generators were cross-platform. That is, that you should be able to
generate make files from Windows or Visual Studio solutions from
Linux.

Over time, I suspect that this has regressed and is no longer true,
but that was the original design.

As far as supporting GCC itself as a compiler on Windows, nothing
(should) prevent you from being able to use the Makefile generator on
Windows and emit makefiles that use CC/CXX on Win. Have you tried?

Just making gyp generate the normal Makefiles or Ninja files that use the gcc toolchain on Windows isn't quite sufficient, as Windows has additional requirements, even under mingw or cygwin -- for example, the name of a binary should end in .exe, and I think you need to add the -fms-extensions flag to gcc's cflags to get it to successfully parse Windows headers.  So unfortunately, gcc-on-Linux, cl-on-Windows, and gcc-on-Windows all require slightly different build files.

In case it wasn't clear, you can install Visual Studio Express just for the toolchain and then use gyp+ninja and bypass the IDE altogether.

If I were to hack this up one approach is to do all the hacking on a Linux box by installing mingw-gcc and wine.  That's how I do a lot of Ninja-on-Windows development.  See

https://github.com/martine/ninja/blob/master/HACKING.md#building-for-windows

for notes.

[Robert Stoddard]

For me, using Visual Studio is a non-starter. My primary mode of development is to build software for Linux Mac and Windows. For Windows, I cross-compile using MinGW on Linux. Since the recent ABI change in GCC, the LIBtoA converter in Google Code doesn't work.

As it stands, the only solution I have for using Chromium Embedded in my software is to completely uproot all of the prior work I've done and switch to Visual Studio.  This is a non-starter for me.

That being said, I came here looking for any support or advice that anybody may have to get GYP to work in a MinGW cross compile.   When I look across the interwebs, I see a lot of people asking the same thing, "how do I get Chromium Embedded to build in MinGW?"  I see that question a lot... without answers.   Anybody out there really know anything about that build system?

[Mark Callow]

On Friday, April 22, 2016 at 2:14:23 AM UTC+9, Robert Stoddard wrote:

That being said, I came here looking for any support or advice that anybody may have to get GYP to work in a MinGW cross compile.   When I look across the interwebs, I see a lot of people asking the same thing, "how do I get Chromium Embedded to build in MinGW?"  I see that question a lot... without answers.   Anybody out there really know anything about that build system?

It is certainly possible to have GYP generate make or ninja files to do a build in MinGW on windows. For a cross-compile you will have create a toolset. E.g

  'make_global_settings': [
    ['AR.emscripten', 'emar'],

    ['CC.emscripten', 'emcc'],
    ['CXX.emscripten', 'emcc'],

    ['LD.emscripten', 'emcc'],
    ['LINK.emscripten', 'emcc'],
  ],

You can then reference it from configurations that should use it with, e.g,

'toolset': 'emscripten',

I haven't completely grokked how to invoke the builds and have them use the desired toolset. With make I found I had to manually add TOOLSET=emscripten on the make command.

As for coping with differing executable extensions etc., you could

1. generate the files on Windows them copy them to Linux :-).
2. override the relevant GYP variable settings, e.g. SHARED_LIB_PREFIX, SHARED_LIB_SUFFIX, from the gyp command line.
3. fix the IMO bug in GYP whereby it always uses a "flavor" based on the generator or the value of Python's sys.platform to determine the default values of these variables. IMO it should use the OS value, if specified on the gyp command line, to determine these.