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

[liruncong2018]

Hi,
Also, It's not really expected that running SCons, having it generate ninja, and running ninja will be faster than just running SCons.
But, if you run scons to generate ninja, and after the first build just run ninja directly, it is expected that further incremental builds would be faster.
Is that what you are trying?

:: "incremental builds would be faster" This is exactly what I need. Our compilation time is longer, the first compilation time is about 3:45, and the second compilation time is about 25s without clearing. Compile time again with ninja enabled may be 18s. The reason why it may be 18s is because the first compilation and linking failed, and the second time it was not linked again, it directly showed that the compilation was successful (no compilation was performed), and the time spent was 18s. I don't know where the problem is yet.




------------------ 原始邮件 ------------------
发件人:                                                                                                                        "SCons users mailing list"                                                                                    <bill at baddogconsulting.com>;
发送时间: 2022年4月13日(星期三) 凌晨0:41
收件人: "SCons users mailing list"<scons-users at scons.org>;

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



Pull requests are welcome if you'd like to enhance the TEMPFILE functionality as you describe.
Or you can always fund a developer to do it.


Also, It's not really expected that running SCons, having it generate ninja, and running ninja will be faster than just running SCons.
But, if you run scons to generate ninja, and after the first build just run ninja directly, it is expected that further incremental builds would be faster.
Is that what you are trying?


Or are you only measuring a single build of scons vs scons building via ninja?




On Tue, Apr 12, 2022 at 8:52 AM liruncong2018 via Scons-users <scons-users at scons.org> wrote:

Hi
I tested "https://github.com/SCons/scons/pull/4133", after enabling ningja, except for the link failure, .c/.cpp/.S are successfully compiled into .o, the total time is 6:48 . 
This time is much greater than the previous time of 3:45 when ninja was not enabled and the option file was shared using @file.
After using TEMPFILE instead of @file, the compilation time is basically doubled whether ninja is enabled or not. 
The TEMPFILE function should be improved to use shared files to prevent the creation of a large number of temporary files.


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

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



I have a potential fix to the ninja tool so that it can decide to use response files or not. This should allow you to use your own shared response file.

https://github.com/SCons/scons/pull/4133



On Mon, Apr 11, 2022 at 10:01 AM Mats Wichmann <mats at wichmann.us> wrote:


 On 4/11/22 08:57, liruncong2018 via Scons-users wrote:
 > 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.
 
 Right... thus my suggestion - well, let's call it "musing" rather than
 "suggestion" because this might not work at all:
 
 > 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
 

_______________________________________________
 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/20220413/872eee12/attachment.htm>