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

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"                                                                                    <[email protected]&gt;;
发送时间:&nbsp;2022年4月11日(星期一) 晚上10:02
收件人:&nbsp;"scons-users"<[email protected]&gt;;

主题:&nbsp;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:
&gt; How long is your normally expanded compile command line (not using
&gt; @__cpp_path.txt) ?&nbsp; -- About 16K bytes(armclang cmd line) or 137K
&gt; bytes(armlink cmd line).
&gt; If you're building with a flavor of mingw (in msys shell?), what's that
&gt; shells maximum? -- The actual compiler armclang, executed on windows,
&gt; windows cmd supports about 2047 bytes.
&gt; You could potentially change the shell being used by SCons and avoid the
&gt; need for response files altogether. -- Wonder if an unrestricted shell
&gt; exists and can be used on windows? cmd.exe is a widely used shell on
&gt; 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.&nbsp; 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.

&gt; In addition, the "TEMPFILE" method cannot be linked here, because the
&gt; linker armlink checks whether there is the --cpu option on the command
&gt; line, and if not, an error is reported. "TEMPFILE" puts all options in a
&gt; 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
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users