[Scons-users] 回复： 回复： 回复： 回复： Ninja compilation fails after using include path file instead of "-I" option

[liruncong2018]

Hi,
Even using msys2 does not solve all problems. The 32K limit solves my compilation problems (.cpp -> .o) but not linking (.o -> target) because the link command line has around 137K (about 2500 .o files). So compilers such as gcc/clang/armclang will support "@file".
Currently, scons needs to set up Depends when using @file. This dependency suggestion is still directly supported by scons, and users do not need to write dependencies. It should also be supported when ninja is enabled.
When LINKCOM uses "TEMPFILE", I get a link failure because armlink.exe checks if --cpu is specified on the command line, so it is not reasonable for "TEMPFILE" to put all options to a temporary file.





------------------ 原始邮件 ------------------
发件人:                                                                                                                        "SCons users mailing list"                                                                                    <mats at wichmann.us>;
发送时间: 2022年4月11日(星期一) 晚上10:02
收件人: "scons-users"<scons-users at scons.org>;

主题: Re: [Scons-users] 回复： 回复： 回复： Ninja compilation fails after using include path file instead of "-I" option



On 4/11/22 07:18, liruncong2018 via Scons-users wrote:
> How long is your normally expanded compile command line (not using
> @__cpp_path.txt) ?  -- About 16K bytes(armclang cmd line) or 137K
> bytes(armlink cmd line).
> If you're building with a flavor of mingw (in msys shell?), what's that
> shells maximum? -- The actual compiler armclang, executed on windows,
> windows cmd supports about 2047 bytes.
> You could potentially change the shell being used by SCons and avoid the
> need for response files altogether. -- Wonder if an unrestricted shell
> exists and can be used on windows? cmd.exe is a widely used shell on
> windows.

If you're running in an msys2 bash shell, the limit is a lot longer:

$ getconf ARG_MAX
32000

However, at the moment, SCons doesn't use the msys bash for executing
the compile commands, so this is kind of a moot point.  I've been an
advocate of changing to do this, but apparently other build tools have
found problems doing so - bazel now recommends not using the msys bash
when building with mingw.

> In addition, the "TEMPFILE" method cannot be linked here, because the
> linker armlink checks whether there is the --cpu option on the command
> line, and if not, an error is reported. "TEMPFILE" puts all options in a
> temporary file, so linking fails.

That's interesting, we should have that recorded somewhere. We already
have some issues that suggest the command name should not be inside the
response file (#1705), perhaps the basic options should not be, either.
That's probably easier for linker commands than compiler commands - for
link commands it's usually a massive list of sources (object files) that
causes the overflow, while for compilers, there can be lots of include
directory paths and other non-source-file stuff that goes into the
command line.

For ninja it currently looks like this:

env["LINKCOM"] = '${TEMPFILE("$LINK $LINKFLAGS /OUT:$TARGET.windows
$_LIBDIRFLAGS $_LIBFLAGS $_PDB $SOURCES.windows", "$LINKCOMSTR")}'

env["SHLINKCOM"] = '${TEMPFILE("$SHLINK $SHLINKFLAGS $_SHLINK_TARGETS
$_LIBDIRFLAGS $_LIBFLAGS $_PDB $_SHLINK_SOURCES", "$SHLINKCOMSTR")}'

So I'm curious if moving $LINK $LINKFLAGS to the left of ${TEMPFILE
would help...

_______________________________________________
Scons-users mailing list
Scons-users at scons.org
https://pairlist4.pair.net/mailman/listinfo/scons-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20220411/f46eee21/attachment.htm>