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

Daniel Moody dmoody256 at gmail.com
Mon Apr 18 11:09:16 EDT 2022


Hello,

Thanks for reporting the issue from ninja, I have updated the branch with a
small fix for that case.

Regarding the scons issues, I added comments inline about the code and some
of the issues I see:

compileIncPath = os.path.normpath(os.path.join(rtconfig.EXEC_PATH, "..",
"include"))
cppPathList = [os.path.join(compileIncPath, "libcxx"), compileIncPath] +
env["CPPPATH"]
cppPathStr = "-I" + "\n-I".join(cppPathList).replace("\\", "/")
incPathsFile = env.Textfile(
    "build/__cpp_path.txt",
cppPathStr
)
env["_CPPINCFLAGS"] = "@%s" % (incPathsFile[0].path.replace("\\", "/"))

exeIncPath = []
for p in env["CPPPATH"]:
    p = p.replace("\\", "/")
    if p.find("compilers") == -1 and not re.search('components/net', p):
        exeIncPath += [p]

exeCppPathStr = "-I" + "\n-I".join(exeIncPath).replace("\\", "/")
exeIncPathsFile = env.Textfile(
    "build/__exe_cpp_path.txt",
    exeCppPathStr
)
env["_ExeIncPathsFile"] = exeIncPathsFile[0].path.replace("\\", "/")

objsList = []
for obj in objs:
    (fileName, ext) = os.path.splitext(obj.path)
    if ext in env["CPPSUFFIXES"] or ext == ".o":
        objsList += [fileName.replace("\\", "/") + ".o"];
    # Daniel Moody: This text file is only dependent on the string list, so
only if the
    # objsList changes would the Textfile be regenerated
    linkObjsFile = env.Textfile(
        "build/__link_objects.txt",
        "\n".join(objsList)
    )
# Daniel Moody: Setting the LINKCOM or any of the COM variables directly is
a very aggressive
# approach and should not be used in most situations.
# Instead you should add the new flags to LINKFLAGS like:
# env.Append(LINKFLAGS=["--via=%s" % (linkObjsFile[0].path.replace("\\",
"/"))])
env["LINKCOM"] = "$LINK -o $TARGET $LINKFLAGS --via=%s" % (linkObjsFile[0
].path.replace("\\", "/"))

defineOptsFile = env.Textfile(
    "build/__define_options.txt",
    "\n".join(rtconfig.rtconfigObj.DefineOptions)
)

incFile = os.path.join(rtconfig.KND_ROOT, "include", "basicdef.h")
cPch = os.path.join(rtconfig.BSP_ROOT, "build", os.path.basename(incFile))
+ ".c.pch"
cppPch = os.path.join(rtconfig.BSP_ROOT, "build", os.path.basename(incFile))
+ ".cpp.pch"

env.Command(
    cPch,
    [incFile, incPathsFile, defineOptsFile],
    ["$CXX -x c-header ${SOURCES[0]} -o $TARGET $CCFLAGS $CFLAGS
$_CPPINCFLAGS @$_DefineOptsFile"]
)

env.Command(
    cppPch,
    [incFile, incPathsFile, defineOptsFile],
    ["$CXX -x c++-header ${SOURCES[0]} -o $TARGET $CCFLAGS $CXXFLAGS
$_CPPINCFLAGS @$_DefineOptsFile"]
)

env["_C_INC_FLAG"] = "-include %s" % (incFile)
env["_CXX_INC_FLAG"] = "-include %s" % (incFile)
env["_C_PCH_FLAG"] = "-include-pch %s" % (cPch)
env["_CXX_PCH_FLAG"] = "-include-pch %s" % (cppPch)

# Daniel Moody: This scanner is for object files only, here I see the use
of exeIncPathsFile and
# linkObjsFile which I assume are not meant to be used with object file
compile commands. I
# think you will want to make a scanner for the Program Builder. The
program builder already has
# a scanner so you will need to chain the scanners like this:
#
# def new_program_scanner(node, env, path, argument):
#     dependencies = argument(node, env, path)
#     dependencies += exeIncPathsFile + linkObjsFile
#     return dependencies

# env['BUILDERS']['Program'].target_scanner = SCons.Scanner.Scanner(
#     function=new_program_scanner,
#     path_function=env['BUILDERS']['Program'].target_scanner.path_function,
#     argument=env['BUILDERS']['Program'].target_scanner
# )
def _add_scanner(builder):
    def new_scanner(node, env, path):
        return defineOptsFile + incPathsFile + exeIncPathsFile +
linkObjsFile + env["_H_Files"] + [cPch] + [cppPch]

    builder.builder.target_scanner = SCons.Scanner.Scanner(
        function=new_scanner,
        path_function=[],
    )
for object_builder in SCons.Tool.createObjBuilders(env):
    _add_scanner(object_builder)

env["_DefineOptsFile"] = defineOptsFile
env["CCCOM"] += " $_C_INC_FLAG $_C_PCH_FLAG @$_DefineOptsFile"
env["CXXCOM"] += " $_CXX_INC_FLAG $_CXX_PCH_FLAG @$_DefineOptsFile"

opts = [
"-Wno-invalid-source-encoding",
"-Wno-invalid-offsetof",
"-Wformat",
"-Wuninitialized",
"-Wfloat-conversion",
"-Wno-unused-variable",
"-Wno-int-to-void-pointer-cast",
"-Wno-deprecated-declarations",
"-Wno-int-to-pointer-cast",
"-std=gnu++17",
"-Wno-c++2a-extensions", # Synonym for -Wno-c++20-extensions.
"-Wno-gnu-string-literal-operator-template", # string literal operator
templates are a GNU extension
"-D__MSVC_INLINE_ASM=",
"-DWIN32"
]
# Daniel Moody: I think you are trying to create dependencies by passing
the response files as a source here?
# I think instead you should use the scanner I recommended in the above
comment.
# also I do not know what rtconfig.TARGET is or why it needs to depend on
the exeTarget
for exeTarget, srcList in env["_ExeTarget"]:
    env.Command(
        exeTarget,
        [srcList, exeIncPathsFile, defineOptsFile],
        [
            "clang++.exe -o $TARGET ${SOURCES[0]} @$_ExeIncPathsFile
$_CXX_INC_FLAG @$_DefineOptsFile %s" % (" ".join(opts))
        ]
    )
env.Depends(rtconfig.TARGET, exeTarget)

On Mon, Apr 18, 2022 at 8:26 AM liruncong2018 <liruncong2018 at qq.com> wrote:

> Hi,
> I get the following error after compiling with branch: "
> https://github.com/dmoody256/scons/tree/ninja_integration_branch"
> ···
> ninja: error:
> D:\work\current\master\bsp\am335x-knd\apps\cnc\build.ninja:268806: unknown
> target 'D'
> default D:\work\current\master\knd\libs\CncSys\K2000PRJ\LimitTime\LimitT...
>          ^ near here
> scons: *** [build.ninja] CalledProcessError : Command 'ninja' returned
> non-zero exit status 1.[error]
> Traceback (most recent call last):
> ···
> "D:\work\current\***" should it be "D$:\work\current\***" ?
>
> In addition, I found that when ninja is not enabled, scons will all be
> recompiled when compiled again, which is equivalent to the first
> compilation.
> From the log, "__link_objects.txt" is generated again, which will cause
> all to be recompiled.
> Below is my code for this part, I don't know if there is a problem. At the
> same time, the last env.Depends inside I don't know how to use scanner
> instead?
> ···
>     compileIncPath = os.path.normpath(os.path.join(rtconfig.EXEC_PATH,
> "..", "include"))
>     cppPathList = [os.path.join(compileIncPath, "libcxx"), compileIncPath]
> + env["CPPPATH"]
>     cppPathStr = "-I" + "\n-I".join(cppPathList).replace("\\", "/")
>     incPathsFile = env.Textfile(
>         "build/__cpp_path.txt",
>         cppPathStr
>     )
>     env["_CPPINCFLAGS"] = "@%s" % (incPathsFile[0].path.replace("\\", "/"))
>
>     exeIncPath = []
>     for p in env["CPPPATH"]:
>         p = p.replace("\\", "/")
>         if p.find("compilers") == -1 and not re.search('components/net',
> p):
>             exeIncPath += [p]
>
>     exeCppPathStr = "-I" + "\n-I".join(exeIncPath).replace("\\", "/")
>     exeIncPathsFile = env.Textfile(
>         "build/__exe_cpp_path.txt",
>         exeCppPathStr
>     )
>     env["_ExeIncPathsFile"] = exeIncPathsFile[0].path.replace("\\", "/")
>
>     objsList = []
>     for obj in objs:
>         (fileName, ext) = os.path.splitext(obj.path)
>         if ext in env["CPPSUFFIXES"] or ext == ".o":
>             objsList += [fileName.replace("\\", "/") + ".o"];
>     linkObjsFile = env.Textfile(
>         "build/__link_objects.txt",
>         "\n".join(objsList)
>     )
>     env["LINKCOM"] = "$LINK -o $TARGET $LINKFLAGS --via=%s" %
> (linkObjsFile[0].path.replace("\\", "/"))
>
>     defineOptsFile = env.Textfile(
>         "build/__define_options.txt",
>         "\n".join(rtconfig.rtconfigObj.DefineOptions)
>     )
>
>     incFile = os.path.join(rtconfig.KND_ROOT, "include", "basicdef.h")
>     cPch = os.path.join(rtconfig.BSP_ROOT, "build",
> os.path.basename(incFile)) + ".c.pch"
>     cppPch = os.path.join(rtconfig.BSP_ROOT, "build",
> os.path.basename(incFile)) + ".cpp.pch"
>
>     env.Command(
>         cPch,
>         [incFile, incPathsFile, defineOptsFile],
>         ["$CXX -x c-header ${SOURCES[0]} -o $TARGET $CCFLAGS $CFLAGS
> $_CPPINCFLAGS @$_DefineOptsFile"]
>     )
>
>     env.Command(
>         cppPch,
>         [incFile, incPathsFile, defineOptsFile],
>         ["$CXX -x c++-header ${SOURCES[0]} -o $TARGET $CCFLAGS $CXXFLAGS
> $_CPPINCFLAGS @$_DefineOptsFile"]
>     )
>
>     env["_C_INC_FLAG"] = "-include %s" % (incFile)
>     env["_CXX_INC_FLAG"] = "-include %s" % (incFile)
>     env["_C_PCH_FLAG"] = "-include-pch %s" % (cPch)
>     env["_CXX_PCH_FLAG"] = "-include-pch %s" % (cppPch)
>
>     def _add_scanner(builder):
>         def new_scanner(node, env, path):
>             return defineOptsFile + incPathsFile + exeIncPathsFile +
> linkObjsFile + env["_H_Files"] + [cPch] + [cppPch]
>
>         builder.builder.target_scanner = SCons.Scanner.Scanner(
>             function=new_scanner,
>             path_function=[],
>         )
>     for object_builder in SCons.Tool.createObjBuilders(env):
>         _add_scanner(object_builder)
>
>     env["_DefineOptsFile"] = defineOptsFile
>     env["CCCOM"] += " $_C_INC_FLAG $_C_PCH_FLAG @$_DefineOptsFile"
>     env["CXXCOM"] += " $_CXX_INC_FLAG $_CXX_PCH_FLAG @$_DefineOptsFile"
>
>     opts = [
>         "-Wno-invalid-source-encoding",
>         "-Wno-invalid-offsetof",
>         "-Wformat",
>         "-Wuninitialized",
>         "-Wfloat-conversion",
>         "-Wno-unused-variable",
>         "-Wno-int-to-void-pointer-cast",
>         "-Wno-deprecated-declarations",
>         "-Wno-int-to-pointer-cast",
>         "-std=gnu++17",
>         "-Wno-c++2a-extensions", # Synonym for -Wno-c++20-extensions.
>         "-Wno-gnu-string-literal-operator-template", # string literal
> operator templates are a GNU extension
>         "-D__MSVC_INLINE_ASM=",
>         "-DWIN32"
>     ]
>     for exeTarget, srcList in env["_ExeTarget"]:
>         env.Command(
>             exeTarget,
>             [srcList, exeIncPathsFile, defineOptsFile],
>             [
>                 "clang++.exe -o $TARGET ${SOURCES[0]} @$_ExeIncPathsFile
> $_CXX_INC_FLAG @$_DefineOptsFile %s" % (" ".join(opts))
>             ]
>         )
>         env.Depends(rtconfig.TARGET, exeTarget)
> ···
>
> ------------------ 原始邮件 ------------------
> *发件人:* "Daniel Moody" <dmoody256 at gmail.com>;
> *发送时间:* 2022年4月18日(星期一) 下午3:36
> *收件人:* "liruncong2018"<liruncong2018 at qq.com>;
> *抄送:* "Bill Deegan"<bill at baddogconsulting.com>;"scons-users"<
> scons-users at scons.org>;
> *主题:* Re: [Scons-users] 回复: 回复: 回复: 回复: 回复: 回复: Ninja compilation fails
> after using include path file instead of "-I" option
>
> Hello liruncong,
>
> I have a test branch for the issues you described where re-running scons
> is not re-compiling, could you please try it out?:
> https://github.com/dmoody256/scons/tree/ninja_integration_branch
>
> On Sun, Apr 17, 2022 at 2:29 AM liruncong2018 <liruncong2018 at qq.com>
> wrote:
>
>> If execute the command "scons -j%NUMBER_OF_PROCESSORS% generate-ninja
>> --verbose --experimental=ninja", it will be completely recompiled.
>> If execute the command again, then it will be completely recompiled.
>> Each time is equivalent to the first compilation.
>>
>> ------------------ 原始邮件 ------------------
>> *发件人:* "Daniel Moody" <dmoody256 at gmail.com>;
>> *发送时间:* 2022年4月17日(星期天) 中午1:52
>> *收件人:* "liruncong2018"<liruncong2018 at qq.com>;
>> *抄送:* "Bill Deegan"<bill at baddogconsulting.com>;"SCons users mailing
>> list"<scons-users at scons.org>;
>> *主题:* Re: [Scons-users] 回复: 回复: 回复: 回复: 回复: 回复: Ninja compilation fails
>> after using include path file instead of "-I" option
>>
>> If you use the command line target 'generate-ninja' for the scons
>> command, does it still fail to build and execute ninja on the second run?
>>
>>
>> On Sat, Apr 16, 2022 at 10:36 PM liruncong2018 <liruncong2018 at qq.com>
>> wrote:
>>
>>> Great, looking forward to your PR!
>>>
>>>
>>> ------------------ 原始邮件 ------------------
>>> *发件人:* "Daniel Moody" <dmoody256 at gmail.com>;
>>> *发送时间:* 2022年4月17日(星期天) 中午11:31
>>> *收件人:* "liruncong2018"<liruncong2018 at qq.com>;
>>> *抄送:* "Bill Deegan"<bill at baddogconsulting.com>;"SCons users mailing
>>> list"<scons-users at scons.org>;
>>> *主题:* Re: [Scons-users] 回复: 回复: 回复: 回复: 回复: 回复: Ninja compilation fails
>>> after using include path file instead of "-I" option
>>>
>>> Okay that indicates that scons is not deciding to build and execute the
>>> ninja file, probably because nothing has changed in the build scripts when
>>> you only change the source file. This is a bug, even if the ninja file is
>>> not regened, scons should execute it for you. I will make a PR for this
>>> issue. For now you will need to use the run_ninja_env.bat.
>>>
>>>
>>> On Sat, Apr 16, 2022 at 9:54 PM liruncong2018 <liruncong2018 at qq.com>
>>> wrote:
>>>
>>>> Hi,
>>>> When I just execute run_ninja_env.bat, it shows compile error. It seems
>>>> that there is no problem with ninja, the problem should be that scons does
>>>> not call run_ninja_env.bat to execute. Now how do I diagnose this problem
>>>> with scons?
>>>> ------------------ 原始邮件 ------------------
>>>> *发件人:* "Daniel Moody" <dmoody256 at gmail.com>;
>>>> *发送时间:* 2022年4月17日(星期天) 上午10:28
>>>> *收件人:* "liruncong2018"<liruncong2018 at qq.com>;
>>>> *抄送:* "Bill Deegan"<bill at baddogconsulting.com>;"SCons users mailing
>>>> list"<scons-users at scons.org>;
>>>> *主题:* Re: [Scons-users] 回复: 回复: 回复: 回复: 回复: 回复: Ninja compilation
>>>> fails after using include path file instead of "-I" option
>>>>
>>>> When I test with the repo https://github.com/liruncong/NinJaTest for
>>>> bsp/beaglebone build using the changes from here:
>>>> https://github.com/SCons/scons/pull/4133, and I put an 'a' in the
>>>> src/irq.c file, I see the file error when I rerun the build.
>>>>
>>>> Could you specify what file you changed?
>>>>
>>>> Also on subsequent runs, you can just run_ninja_env.bat, it will skip
>>>> scons regeneration, but if you want scons to regen it should work also.
>>>>
>>>> On Sat, Apr 16, 2022 at 8:46 PM liruncong2018 <liruncong2018 at qq.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> After the first compilation is successful, modify the file, expect the
>>>>> compilation to fail, but compile again without error message.
>>>>> The following is the log after the command("scons
>>>>> -j%NUMBER_OF_PROCESSORS% --verbose --experimental=ninja") is executed:
>>>>> ______________________________________
>>>>> scons: Reading SConscript files ...
>>>>> scons: done reading SConscript files.
>>>>> scons: Building targets ...
>>>>> scons: done building targets.
>>>>> ______________________________________
>>>>> I have attached the compressed "build.ninja" file in the attachment.
>>>>>
>>>>> ------------------ 原始邮件 ------------------
>>>>> *发件人:* "Daniel Moody" <dmoody256 at gmail.com>;
>>>>> *发送时间:* 2022年4月17日(星期天) 凌晨1:53
>>>>> *收件人:* "Bill Deegan"<bill at baddogconsulting.com>;
>>>>> *抄送:* "SCons users mailing list"<scons-users at scons.org
>>>>> >;"liruncong2018"<liruncong2018 at qq.com>;
>>>>> *主题:* Re: [Scons-users] 回复: 回复: 回复: 回复: 回复: 回复: Ninja compilation
>>>>> fails after using include path file instead of "-I" option
>>>>>
>>>>> Also i realized that link_objects.txt is probably not meant for the
>>>>> object builders. I assume this file is intended for linking the libraries
>>>>> and programs? In that case you will want a scanner for those builders
>>>>> instead. Do you have error messages you can show, it should help to see
>>>>> what your issue is.
>>>>>
>>>>> On Sat, Apr 16, 2022, 10:58 AM Bill Deegan <bill at baddogconsulting.com>
>>>>> wrote:
>>>>>
>>>>>> try bzip'ing the ninja.build file. That should make it considerably
>>>>>> smaller.
>>>>>>
>>>>>> On Sat, Apr 16, 2022 at 4:37 PM liruncong2018 via Scons-users <
>>>>>> scons-users at scons.org> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> Still the same problem. I want to send "build.ninja" as an
>>>>>>> attachment, but the email always bounces, what information can I print so I
>>>>>>> can find the problem?
>>>>>>>
>>>>>>> ------------------ 原始邮件 ------------------
>>>>>>> *发件人:* "Daniel Moody" <dmoody256 at gmail.com>;
>>>>>>> *发送时间:* 2022年4月16日(星期六) 凌晨0:29
>>>>>>> *收件人:* "liruncong2018"<liruncong2018 at qq.com>;
>>>>>>> *抄送:* "SCons users mailing list"<scons-users at scons.org>;
>>>>>>> *主题:* Re: [Scons-users] 回复: 回复: 回复: 回复: 回复: Ninja compilation fails
>>>>>>> after using include path file instead of "-I" option
>>>>>>>
>>>>>>> Here's the same code but better color scheme:
>>>>>>>
>>>>>>> incPathsFile = env.Textfile(
>>>>>>>     "build/__cpp_path.txt",
>>>>>>>     cppPathStr
>>>>>>> )
>>>>>>>
>>>>>>> defineOptsFile = env.Textfile(
>>>>>>>     "build/__define_options.txt",
>>>>>>>     "\n".join(rtconfig.rtconfigObj.DefineOptions)
>>>>>>> )
>>>>>>>
>>>>>>> linkObjsFile = env.Textfile(
>>>>>>>     "build/__link_objects.txt",
>>>>>>>     "\n".join(objsList)
>>>>>>> )
>>>>>>>
>>>>>>> def _add_scanner(builder):
>>>>>>>     def new_scanner(node, env, path):
>>>>>>>         return incPathsFile + defineOptsFile + linkObjsFile
>>>>>>>
>>>>>>>     builder.builder.target_scanner = SCons.Scanner.Scanner(
>>>>>>>         function=new_scanner,
>>>>>>>         path_function=[],
>>>>>>>     )
>>>>>>> for object_builder in SCons.Tool.createObjBuilders(env):
>>>>>>>     _add_scanner(object_builder)
>>>>>>>
>>>>>>> On Fri, Apr 15, 2022 at 10:50 AM Daniel Moody <dmoody256 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> hello liruncong,
>>>>>>>>
>>>>>>>> If you want to add multiple @file dependencies via the scanner do
>>>>>>>> them all in the same scanner. Like I said you can only apply one scanner,
>>>>>>>> so in this case you are overwriting each previous scanner. The scanner
>>>>>>>> should return a list of files in which to set dependencies for the current
>>>>>>>> node.
>>>>>>>>
>>>>>>>> The path function is not used in this case, and I just left the
>>>>>>>> CPPPATH from the default SourceFileScanner I copied the scanner code from.
>>>>>>>> It does have to be something besides None I believe though, or scons won't
>>>>>>>> scan. The correct way this should be used in this case is you should place
>>>>>>>> the @file in a known list of directories or just a single directory, and
>>>>>>>> then pass a list of directories or a list containing the single directory,
>>>>>>>> and the scanner should find the files by extension in the list of
>>>>>>>> directories. This is the fundamental working of scanners if you want to
>>>>>>>> read more:
>>>>>>>> https://scons.org/doc/production/HTML/scons-user/ch20.html,
>>>>>>>> however you could also use a dummy list if there is no dynamic component
>>>>>>>> here.
>>>>>>>>
>>>>>>>> Here is an updated example based on the new info you provided:
>>>>>>>>
>>>>>>>> incPathsFile = env.Textfile(
>>>>>>>>     "build/__cpp_path.txt",
>>>>>>>>     cppPathStr
>>>>>>>> )
>>>>>>>>
>>>>>>>> defineOptsFile = env.Textfile(
>>>>>>>>     "build/__define_options.txt",
>>>>>>>>     "\n".join(rtconfig.rtconfigObj.DefineOptions)
>>>>>>>> )
>>>>>>>>
>>>>>>>> linkObjsFile = env.Textfile(
>>>>>>>>     "build/__link_objects.txt",
>>>>>>>>     "\n".join(objsList)
>>>>>>>> )
>>>>>>>>
>>>>>>>> def _add_scanner(builder):
>>>>>>>>     def new_scanner(node, env, path):
>>>>>>>>         return incPathsFile + defineOptsFile + linkObjsFile
>>>>>>>>
>>>>>>>>     builder.builder.target_scanner = SCons.Scanner.Scanner(
>>>>>>>>         function=new_scanner,
>>>>>>>>         path_function=[],
>>>>>>>>     )
>>>>>>>> for object_builder in SCons.Tool.createObjBuilders(env):
>>>>>>>>     _add_scanner(object_builder)
>>>>>>>>
>>>>>>>> On Fri, Apr 15, 2022 at 9:58 AM liruncong2018 <liruncong2018 at qq.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Can you give me more information? What source file? Does the
>>>>>>>>> compilation fail the first time? Does it recompile successfully with only
>>>>>>>>> scons building? Can you push your latest code so I can see it in your repo?
>>>>>>>>> -- I don't know how to reproduce this problem in the git test
>>>>>>>>> project, I will try to see if it can be reproduced.
>>>>>>>>> Also each builder can only hold one target or source scanner, but
>>>>>>>>> you can chain the scanner by calling other scanners from within the single
>>>>>>>>> scanner. Are you assigning multiple scanners to the same builder?
>>>>>>>>> -- The following are some scanners, I don't quite understand the
>>>>>>>>> path_function, especially the second parameter of the last scanner
>>>>>>>>> (linkObjsFile).
>>>>>>>>> ————————————————————————————————————————
>>>>>>>>>     incPathsFile = env.Textfile(
>>>>>>>>>         "build/__cpp_path.txt",
>>>>>>>>>         cppPathStr
>>>>>>>>>     )
>>>>>>>>>     def _add_scanner(builder):
>>>>>>>>>         def new_scanner(node, env, path):
>>>>>>>>>             return incPathsFile
>>>>>>>>>
>>>>>>>>>         builder.builder.target_scanner = SCons.Scanner.Scanner(
>>>>>>>>>             function=new_scanner,
>>>>>>>>>             path_function=SCons.Script.FindPathDirs('CPPPATH'),
>>>>>>>>>         )
>>>>>>>>>     for object_builder in SCons.Tool.createObjBuilders(env):
>>>>>>>>>         _add_scanner(object_builder)
>>>>>>>>>
>>>>>>>>>     defineOptsFile = env.Textfile(
>>>>>>>>>         "build/__define_options.txt",
>>>>>>>>>         "\n".join(rtconfig.rtconfigObj.DefineOptions)
>>>>>>>>>     )
>>>>>>>>>
>>>>>>>>>     def _add_scanner(builder):
>>>>>>>>>         def new_scanner(node, env, path):
>>>>>>>>>             return defineOptsFile
>>>>>>>>>
>>>>>>>>>         builder.builder.target_scanner = SCons.Scanner.Scanner(
>>>>>>>>>             function=new_scanner,
>>>>>>>>>             path_function=SCons.Script.FindPathDirs('CPPPATH'),
>>>>>>>>>         )
>>>>>>>>>     for object_builder in SCons.Tool.createObjBuilders(env):
>>>>>>>>>         _add_scanner(object_builder)
>>>>>>>>>
>>>>>>>>>     linkObjsFile = env.Textfile(
>>>>>>>>>         "build/__link_objects.txt",
>>>>>>>>>         "\n".join(objsList)
>>>>>>>>>     )
>>>>>>>>>
>>>>>>>>>     def _add_scanner(builder):
>>>>>>>>>         def new_scanner(node, env, path):
>>>>>>>>>             return linkObjsFile
>>>>>>>>>
>>>>>>>>>         builder.builder.target_scanner = SCons.Scanner.Scanner(
>>>>>>>>>             function=new_scanner,
>>>>>>>>>             path_function=SCons.Script.FindPathDirs('LIBPATH'),
>>>>>>>>>         )
>>>>>>>>>     for object_builder in SCons.Tool.createObjBuilders(env):
>>>>>>>>>         _add_scanner(object_builder)
>>>>>>>>> ————————————————————————————————————————————————
>>>>>>>>> ------------------ 原始邮件 ------------------
>>>>>>>>> *发件人:* "Daniel Moody" <dmoody256 at gmail.com>;
>>>>>>>>> *发送时间:* 2022年4月14日(星期四) 晚上11:36
>>>>>>>>> *收件人:* "liruncong2018"<liruncong2018 at qq.com>;
>>>>>>>>> *抄送:* "SCons users mailing list"<scons-users at scons.org>;
>>>>>>>>> *主题:* Re: [Scons-users] 回复: 回复: 回复: 回复: 回复: Ninja compilation
>>>>>>>>> fails after using include path file instead of "-I" option
>>>>>>>>>
>>>>>>>>> Can you give me more information? What source file? Does the
>>>>>>>>> compilation fail the first time? Does it recompile successfully with only
>>>>>>>>> scons building? Can you push your latest code so I can see it in your repo?
>>>>>>>>>
>>>>>>>>>  Also each builder can only hold one target or source scanner, but
>>>>>>>>> you can chain the scanner by calling other scanners from within the single
>>>>>>>>> scanner. Are you assigning multiple scanners to the same builder?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Apr 14, 2022 at 10:17 AM liruncong2018 <
>>>>>>>>> liruncong2018 at qq.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hello Daniel Moody,
>>>>>>>>>> Thanks a lot for the example you gave. According to your example,
>>>>>>>>>> I added 4 scanners, which can indeed be compiled and linked.
>>>>>>>>>> But when I edit the source file, I deliberately put "a" at the
>>>>>>>>>> end of the .cpp file and expect the compilation to fail. But when I compile
>>>>>>>>>> again, nothing compiles.
>>>>>>>>>> How to diagnose this problem?
>>>>>>>>>>
>>>>>>>>>> ------------------ 原始邮件 ------------------
>>>>>>>>>> *发件人:* "Daniel Moody" <dmoody256 at gmail.com>;
>>>>>>>>>> *发送时间:* 2022年4月14日(星期四) 凌晨2:27
>>>>>>>>>> *收件人:* "liruncong2018"<liruncong2018 at qq.com>;
>>>>>>>>>> *抄送:* "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 added an example how to hook up the dependencies:
>>>>>>>>>>
>>>>>>>>>> https://github.com/liruncong/NinJaTest/pull/1/files
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 13, 2022 at 10:01 AM liruncong2018 <
>>>>>>>>>> liruncong2018 at qq.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> I generate some option files via env.Textfile
>>>>>>>>>>> ("build/__cpp_path.txt", "build/__define_options.txt",
>>>>>>>>>>> "build/__link_objects.txt", "build/__exe_cpp_path.txt") and make objs
>>>>>>>>>>> depend on corresponding files ,for example:
>>>>>>>>>>> env.Depends(objs, ["build/__cpp_path.txt",
>>>>>>>>>>> "build/__define_options.txt" ])
>>>>>>>>>>> env.Depends(target, "build/__link_objects.txt")
>>>>>>>>>>> But after enabling ninja, these manually added dependencies are
>>>>>>>>>>> ignored, which causes ninja to fail to compile.
>>>>>>>>>>> How to deal with this?
>>>>>>>>>>>
>>>>>>>>>>> ------------------ 原始邮件 ------------------
>>>>>>>>>>> *发件人:* "Daniel Moody" <dmoody256 at gmail.com>;
>>>>>>>>>>> *发送时间:* 2022年4月13日(星期三) 凌晨0:02
>>>>>>>>>>> *收件人:* "SCons users mailing list"<scons-users at scons.org>;
>>>>>>>>>>> *抄送:* "liruncong2018"<liruncong2018 at qq.com>;
>>>>>>>>>>> *主题:* Re: [Scons-users] 回复: 回复: 回复: 回复: 回复: Ninja compilation
>>>>>>>>>>> fails after using include path file instead of "-I" option
>>>>>>>>>>>
>>>>>>>>>>> Hello, that PR is meant to support shared @file with ninja, not
>>>>>>>>>>> intended for any improvements to TEMPFILE. Please test without TEMPFILE.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Apr 12, 2022 at 10: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
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>> 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/20220418/9778ead4/attachment-0001.htm>


More information about the Scons-users mailing list