It would be nice to support mingw for windows native builds, as well as linux cross compiles and
with clang support
I know this would imply some deep changes, but would be beneficial to gn-build users

So it would then support

• mingw on windows
• mingw on linux
• clang + mingw runtime on linux
• clang + mingw runtime on windows
• clang + msvc runtime on linux (nice to have, but not necessary)

Here is the point:

However, in a Chinese version of cl.exe:

r'Version ([0-9.]+)' doesn't work.
A suggestion is to replace it with r' ([0-9.]+) ' .

Many ldflags like -Wl,--as-needed, pass to ld and got "unknow option" error.

Is there anyone find that this build-gn config would run cost about 20 seconds, while running first time.

With the help of gn help --tracelog and Chrome://tracing，I found \\build\toolchain\win\toolchain.py cost most of time in that process.

I had a idea to verify the guess, so I rewrote the \\build\toolchain\win\toolchain.py， finally make it(Just a fake print).

Then I figured out that, multiple processes were executed concurrently during its execution, which took too much time due to the slow running of VC\Auxiliary\Build\vcvars32.bat.
Compared with other compilers such as vs2013, the execution time of VC\vcvarsall.bat is very fast and the time consumed is very short.

I this way, I found that just run VC\Auxiliary\Build\vcvars32.bat once is enough, in the latest chromium’s build-gn config. But this implemention should introduce some python scripts: \\build\toolchain\win\setup_toolchain.py and \\build\vs_toolchain.py. Besides, some modifies needed.

Is there anyone else agree with the idea?

Mac OS
gn gen ./out --args='target_os="ios" target_cpu="arm64"'

Hi,

Thanks a lot for maintaining this.

I'm currently having issues with a project that has source files with the same name across different folders. This results with different .obj files with the same name in the same directory, without keeping the original folder hierarchy.
Would it be possible to output these while reproducing the original folder structure?

Failed in Mac with:

ERROR at //build/config/mac/BUILD.gn:134:7: Unsupported value in libs.
      "AppKit.framework",
      ^-----------------
Use frameworks to list framework dependencies.

gn

gn --version
1934 (69ec4fca)

Date: Wed Aug 11 10:14:05 2021 -0700

First of all thank you for this great work, this repo was the only way to get GN working for me.
Is this going to be maintained?

Hey, maybe you can help with this: I tried to to change the sdk version to 8.1 but these settings have no effect. both the generated vs project and the ninja files points to latest win10 sdk.

here are my changes in win/settings.gni

declare_args() {
  # Version of Visual Studio pointed to by the visual_studio_path.
  # Use "2013" for Visual Studio 2013.
  visual_studio_version = "2017"

  # Path to Visual Studio.
  visual_studio_path = ""

  # Windows SDK version to use.
  # Can either be a full Windows 10 SDK number (e.g. 10.0.10240.0),
  # "8.1" for the Windows8.1 SDK or "default" to use the VS default version.
  windows_sdk_version = "8.1"

  # Full path to the Windows SDK, not including a backslash at the end.
  # This value is the default location, override if you have a different
  # installation location.
  windows_sdk_path = "C:\Program Files (x86)\Windows Kits\8.1"

  # Microsoft compiler version number clang-cl will report in _MSC_VER
  # (Defaults to the default version associated with the chosen VS version.)
  clang_msc_ver = 0
}

I looked at SetupToolchain function, and it passing only the sdk version from the settings, the path seems ignored.

Is this the original win/toolchain.py file or you've modified it?
I'm wondering if it needs update from chromium.

🤣I know that it is a bit difficult to separate and decouple some code from the chromium project, but it would be great if this repo can supports iOS/macOS framework bundle template from chromium/build/config/ios/rules.gni, chromium/build/config/mac/rules.gni 🙏🥰

Trying to include a header from another target fails. I don't know what I'm doing wrong since the following testcase works with a different build config

I created a testcase that will fail with latest commit

A depfile makes it possilbe that ninja would re-compile when headers changed.
However, when is_win, there is no depfile.

How about

      depsformat = "msvc"

--->

      if (!toolchain_uses_clang) {
        depsformat = "msvc"
        depsflags = ""
      } else {
        depfile = "{{output}}.d"
        depsflags = "-Xclang -dependency-file -Xclang \"$depfile\" " +
                    "-Xclang -MT -Xclang {{source}} -Xclang -MP -Xclang -MG"
        depsformat = "gcc"
      }

and

      command = "$env_wrapper$cl /nologo /FC $sys_include_flags{{defines}} {{include_dirs}} {{cflags}} {{cflags_c}} /c {{source}} /Fo{{output}} /Fd\"$pdbname\""

--->

      command = "$env_wrapper$cl /nologo /FC $sys_include_flags{{defines}} {{include_dirs}} ${depsflags} {{cflags}} {{cflags_c}} /c {{source}} /Fo{{output}} /Fd\"$pdbname\""

Refs:

denoland/deno#1525

denoland/chromium_build@75a7f82...1e3840b

My idea:

Add import("//BUILDCONFIG.gn") to the top of config/BUILDCONFIG.gn. That would allow users of these build scripts to define their own settings before config/BUILDCONFIG.gn is executed.

1>[1/2] CXX obj/test/test_atomic/test_atomic/test_atomic.obj
1>[2/2] LINK test_atomic.exe test_atomic.exe.pdb
1>FAILED: test_atomic.exe test_atomic.exe.pdb
1>ninja -t msvc -e environment_x86 -- link.exe /nologo "-libpath:..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\ATLMFC\lib\x86" "-libpath:..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\lib\x86" "-libpath:..\..\..\..\..\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\ucrt\x86" "-libpath:..\..\..\..\..\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x86" /OUT:./test_atomic.exe /PDB:./test_atomic.exe.pdb @./test_atomic.exe.rsp
1>test_atomic.obj : error LNK2019: unresolved external symbol ___atomic_compare_exchange_8 referenced in function _main
1>./test_atomic.exe : fatal error LNK1120: 1 unresolved externals

The problem happens in windows 10, using Clang-cl in Win32:

test\test_atomic\test_atomic.cpp

#include <atomic>
#include <cinttypes>

int main(void) {
  std::atomic<std::int64_t> temp;
  temp.load();
}

test\test_atomic\build.gn

executable("test_atomic") {
  sources = [
    "test_atomic.cpp",
  ]
}

gn && ninja command line

gn gen out/llvm_win32_release --ide=vs2017 --winsdk=10.0.17763.0 --args="clang_base_path=\"C:/Program Files/LLVM\" is_clang=true target_cpu=\"x86\" is_debug=false"

ninja -C out/llvm_win32_release test_atomic

PS: The problem just happens in LLVM+Win32. There are no problem with LLVM+Win64, Win32 and Win64.