[Scons-users] Scons Implicity Dependency not found issue

[Hua Yanghao]

scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
Implicit dependency
`build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not found,
needed by target `build/configs/pangu/usw/firmware/arch/pangu/test.os'

I recently run into this odd problem, and it is very difficult to
reproduce. I did not explicitly enable the "implicit_cache" option
anywhere in my code. If I simply remove the build folder and then
re-build everything works as normal. the problem happens when there is
a old build, and then I pulled in some new code where this "test.c"
has included an additional header io.h and scons seems not re-scanning
the file by default.

I am using scons 3.0.1, is the implict_cache by default enabled there
and I have to disable it manually?

Thanks,
Yanghao Hua

[Hua Yanghao]

By the way, is scons scanner scans C file headers recursively? Thanks.
On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <***@gmail.com> wrote:
>
> scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
> Implicit dependency
> `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not found,
> needed by target `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>
> I recently run into this odd problem, and it is very difficult to
> reproduce. I did not explicitly enable the "implicit_cache" option
> anywhere in my code. If I simply remove the build folder and then
> re-build everything works as normal. the problem happens when there is
> a old build, and then I pulled in some new code where this "test.c"
> has included an additional header io.h and scons seems not re-scanning
> the file by default.
>
> I am using scons 3.0.1, is the implict_cache by default enabled there
> and I have to disable it manually?
>
> Thanks,
> Yanghao Hua

[Bill Deegan]

Yes. Headers are scanned recursively.
Implicit cache should only be enable by command line flag or SetOption()

Where is io.h located? is it in your CPPPATH?

On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <***@gmail.com> wrote:

> By the way, is scons scanner scans C file headers recursively? Thanks.
> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <***@gmail.com> wrote:
> >
> > scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
> > Implicit dependency
> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not found,
> > needed by target `build/configs/pangu/usw/firmware/arch/pangu/test.os'
> >
> > I recently run into this odd problem, and it is very difficult to
> > reproduce. I did not explicitly enable the "implicit_cache" option
> > anywhere in my code. If I simply remove the build folder and then
> > re-build everything works as normal. the problem happens when there is
> > a old build, and then I pulled in some new code where this "test.c"
> > has included an additional header io.h and scons seems not re-scanning
> > the file by default.
> >
> > I am using scons 3.0.1, is the implict_cache by default enabled there
> > and I have to disable it manually?
> >
> > Thanks,
> > Yanghao Hua
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Hua Yanghao]

Hi Bill,
Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
SConscript files. So normally all used header files will end up in the
build folder too. But occasionally scons seems missed it. I am
struggling to reproduce it ...

BR, Yanghao
On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <***@baddogconsulting.com> wrote:
>
> Yes. Headers are scanned recursively.
> Implicit cache should only be enable by command line flag or SetOption()
>
> Where is io.h located? is it in your CPPPATH?
>
> On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <***@gmail.com> wrote:
>>
>> By the way, is scons scanner scans C file headers recursively? Thanks.
>> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <***@gmail.com> wrote:
>> >
>> > scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>> > Implicit dependency
>> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not found,
>> > needed by target `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>> >
>> > I recently run into this odd problem, and it is very difficult to
>> > reproduce. I did not explicitly enable the "implicit_cache" option
>> > anywhere in my code. If I simply remove the build folder and then
>> > re-build everything works as normal. the problem happens when there is
>> > a old build, and then I pulled in some new code where this "test.c"
>> > has included an additional header io.h and scons seems not re-scanning
>> > the file by default.
>> >
>> > I am using scons 3.0.1, is the implict_cache by default enabled there
>> > and I have to disable it manually?
>> >
>> > Thanks,
>> > Yanghao Hua
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users

[Bill Deegan]

Is io.h a generated file?
Paste the compile line for the compile which should find io.h when it's
passing?


On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <***@gmail.com> wrote:

> Hi Bill,
> Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
> SConscript files. So normally all used header files will end up in the
> build folder too. But occasionally scons seems missed it. I am
> struggling to reproduce it ...
>
> BR, Yanghao
> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <***@baddogconsulting.com>
> wrote:
> >
> > Yes. Headers are scanned recursively.
> > Implicit cache should only be enable by command line flag or SetOption()
> >
> > Where is io.h located? is it in your CPPPATH?
> >
> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <***@gmail.com>
> wrote:
> >>
> >> By the way, is scons scanner scans C file headers recursively? Thanks.
> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <***@gmail.com>
> wrote:
> >> >
> >> > scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
> >> > Implicit dependency
> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not found,
> >> > needed by target `build/configs/pangu/usw/firmware/arch/pangu/test.os'
> >> >
> >> > I recently run into this odd problem, and it is very difficult to
> >> > reproduce. I did not explicitly enable the "implicit_cache" option
> >> > anywhere in my code. If I simply remove the build folder and then
> >> > re-build everything works as normal. the problem happens when there is
> >> > a old build, and then I pulled in some new code where this "test.c"
> >> > has included an additional header io.h and scons seems not re-scanning
> >> > the file by default.
> >> >
> >> > I am using scons 3.0.1, is the implict_cache by default enabled there
> >> > and I have to disable it manually?
> >> >
> >> > Thanks,
> >> > Yanghao Hua
> >> _______________________________________________
> >> Scons-users mailing list
> >> Scons-***@scons.org
> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >
> > _______________________________________________
> > Scons-users mailing list
> > Scons-***@scons.org
> > https://pairlist4.pair.net/mailman/listinfo/scons-users
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Hua Yanghao]

no it is static file.

On Tue 16. Oct 2018 at 17:08, Bill Deegan <***@baddogconsulting.com> wrote:

> Is io.h a generated file?
> Paste the compile line for the compile which should find io.h when it's
> passing?
>
>
> On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <***@gmail.com> wrote:
>
>> Hi Bill,
>> Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
>> SConscript files. So normally all used header files will end up in the
>> build folder too. But occasionally scons seems missed it. I am
>> struggling to reproduce it ...
>>
>> BR, Yanghao
>> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <***@baddogconsulting.com>
>> wrote:
>> >
>> > Yes. Headers are scanned recursively.
>> > Implicit cache should only be enable by command line flag or SetOption()
>> >
>> > Where is io.h located? is it in your CPPPATH?
>> >
>> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <***@gmail.com>
>> wrote:
>> >>
>> >> By the way, is scons scanner scans C file headers recursively? Thanks.
>> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <***@gmail.com>
>> wrote:
>> >> >
>> >> > scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>> >> > Implicit dependency
>> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not found,
>> >> > needed by target
>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>> >> >
>> >> > I recently run into this odd problem, and it is very difficult to
>> >> > reproduce. I did not explicitly enable the "implicit_cache" option
>> >> > anywhere in my code. If I simply remove the build folder and then
>> >> > re-build everything works as normal. the problem happens when there
>> is
>> >> > a old build, and then I pulled in some new code where this "test.c"
>> >> > has included an additional header io.h and scons seems not
>> re-scanning
>> >> > the file by default.
>> >> >
>> >> > I am using scons 3.0.1, is the implict_cache by default enabled there
>> >> > and I have to disable it manually?
>> >> >
>> >> > Thanks,
>> >> > Yanghao Hua
>> >> _______________________________________________
>> >> Scons-users mailing list
>> >> Scons-***@scons.org
>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>> >
>> > _______________________________________________
>> > Scons-users mailing list
>> > Scons-***@scons.org
>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Bill Deegan]

Is `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' the correct
path to io.h?
Are you using duplicate=0, or not specifying in you SConscript()?
Are you using chdir somewhere in your SCons logic?

Also, please paste the compile line for the compile which should find io.h
when it's passing?

On Tue, Oct 16, 2018 at 11:14 AM Hua Yanghao <***@gmail.com> wrote:

> no it is static file.
>
> On Tue 16. Oct 2018 at 17:08, Bill Deegan <***@baddogconsulting.com>
> wrote:
>
>> Is io.h a generated file?
>> Paste the compile line for the compile which should find io.h when it's
>> passing?
>>
>>
>> On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <***@gmail.com> wrote:
>>
>>> Hi Bill,
>>> Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
>>> SConscript files. So normally all used header files will end up in the
>>> build folder too. But occasionally scons seems missed it. I am
>>> struggling to reproduce it ...
>>>
>>> BR, Yanghao
>>> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <***@baddogconsulting.com>
>>> wrote:
>>> >
>>> > Yes. Headers are scanned recursively.
>>> > Implicit cache should only be enable by command line flag or
>>> SetOption()
>>> >
>>> > Where is io.h located? is it in your CPPPATH?
>>> >
>>> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <***@gmail.com>
>>> wrote:
>>> >>
>>> >> By the way, is scons scanner scans C file headers recursively? Thanks.
>>> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <***@gmail.com>
>>> wrote:
>>> >> >
>>> >> > scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>>> >> > Implicit dependency
>>> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not
>>> found,
>>> >> > needed by target
>>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>>> >> >
>>> >> > I recently run into this odd problem, and it is very difficult to
>>> >> > reproduce. I did not explicitly enable the "implicit_cache" option
>>> >> > anywhere in my code. If I simply remove the build folder and then
>>> >> > re-build everything works as normal. the problem happens when there
>>> is
>>> >> > a old build, and then I pulled in some new code where this "test.c"
>>> >> > has included an additional header io.h and scons seems not
>>> re-scanning
>>> >> > the file by default.
>>> >> >
>>> >> > I am using scons 3.0.1, is the implict_cache by default enabled
>>> there
>>> >> > and I have to disable it manually?
>>> >> >
>>> >> > Thanks,
>>> >> > Yanghao Hua
>>> >> _______________________________________________
>>> >> Scons-users mailing list
>>> >> Scons-***@scons.org
>>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>> >
>>> > _______________________________________________
>>> > Scons-users mailing list
>>> > Scons-***@scons.org
>>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-***@scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Hua Yanghao]

it is the correct path and io.h is actually duplicated from
firmware/include/io.h

On Tue 16. Oct 2018 at 17:34, Bill Deegan <***@baddogconsulting.com> wrote:

> Is `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' the correct
> path to io.h?
> Are you using duplicate=0, or not specifying in you SConscript()?
> Are you using chdir somewhere in your SCons logic?
>
> Also, please paste the compile line for the compile which should find io.h
> when it's passing?
>
> On Tue, Oct 16, 2018 at 11:14 AM Hua Yanghao <***@gmail.com> wrote:
>
>> no it is static file.
>>
>> On Tue 16. Oct 2018 at 17:08, Bill Deegan <***@baddogconsulting.com>
>> wrote:
>>
>>> Is io.h a generated file?
>>> Paste the compile line for the compile which should find io.h when it's
>>> passing?
>>>
>>>
>>> On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <***@gmail.com>
>>> wrote:
>>>
>>>> Hi Bill,
>>>> Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
>>>> SConscript files. So normally all used header files will end up in the
>>>> build folder too. But occasionally scons seems missed it. I am
>>>> struggling to reproduce it ...
>>>>
>>>> BR, Yanghao
>>>> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <***@baddogconsulting.com>
>>>> wrote:
>>>> >
>>>> > Yes. Headers are scanned recursively.
>>>> > Implicit cache should only be enable by command line flag or
>>>> SetOption()
>>>> >
>>>> > Where is io.h located? is it in your CPPPATH?
>>>> >
>>>> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <***@gmail.com>
>>>> wrote:
>>>> >>
>>>> >> By the way, is scons scanner scans C file headers recursively?
>>>> Thanks.
>>>> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <***@gmail.com>
>>>> wrote:
>>>> >> >
>>>> >> > scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>>>> >> > Implicit dependency
>>>> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not
>>>> found,
>>>> >> > needed by target
>>>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>>>> >> >
>>>> >> > I recently run into this odd problem, and it is very difficult to
>>>> >> > reproduce. I did not explicitly enable the "implicit_cache" option
>>>> >> > anywhere in my code. If I simply remove the build folder and then
>>>> >> > re-build everything works as normal. the problem happens when
>>>> there is
>>>> >> > a old build, and then I pulled in some new code where this "test.c"
>>>> >> > has included an additional header io.h and scons seems not
>>>> re-scanning
>>>> >> > the file by default.
>>>> >> >
>>>> >> > I am using scons 3.0.1, is the implict_cache by default enabled
>>>> there
>>>> >> > and I have to disable it manually?
>>>> >> >
>>>> >> > Thanks,
>>>> >> > Yanghao Hua
>>>> >> _______________________________________________
>>>> >> Scons-users mailing list
>>>> >> Scons-***@scons.org
>>>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>> >
>>>> > _______________________________________________
>>>> > Scons-users mailing list
>>>> > Scons-***@scons.org
>>>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-***@scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-***@scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Bill Deegan]

You've still not replied with the compile command line.
Also what's your CPPPATH?


On Tue, Oct 16, 2018 at 1:25 PM Hua Yanghao <***@gmail.com> wrote:

> it is the correct path and io.h is actually duplicated from
> firmware/include/io.h
>
> On Tue 16. Oct 2018 at 17:34, Bill Deegan <***@baddogconsulting.com>
> wrote:
>
>> Is `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' the correct
>> path to io.h?
>> Are you using duplicate=0, or not specifying in you SConscript()?
>> Are you using chdir somewhere in your SCons logic?
>>
>> Also, please paste the compile line for the compile which should find
>> io.h when it's passing?
>>
>> On Tue, Oct 16, 2018 at 11:14 AM Hua Yanghao <***@gmail.com>
>> wrote:
>>
>>> no it is static file.
>>>
>>> On Tue 16. Oct 2018 at 17:08, Bill Deegan <***@baddogconsulting.com>
>>> wrote:
>>>
>>>> Is io.h a generated file?
>>>> Paste the compile line for the compile which should find io.h when it's
>>>> passing?
>>>>
>>>>
>>>> On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <***@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Bill,
>>>>> Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
>>>>> SConscript files. So normally all used header files will end up in the
>>>>> build folder too. But occasionally scons seems missed it. I am
>>>>> struggling to reproduce it ...
>>>>>
>>>>> BR, Yanghao
>>>>> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <***@baddogconsulting.com>
>>>>> wrote:
>>>>> >
>>>>> > Yes. Headers are scanned recursively.
>>>>> > Implicit cache should only be enable by command line flag or
>>>>> SetOption()
>>>>> >
>>>>> > Where is io.h located? is it in your CPPPATH?
>>>>> >
>>>>> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <***@gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> By the way, is scons scanner scans C file headers recursively?
>>>>> Thanks.
>>>>> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <***@gmail.com>
>>>>> wrote:
>>>>> >> >
>>>>> >> > scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>>>>> >> > Implicit dependency
>>>>> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not
>>>>> found,
>>>>> >> > needed by target
>>>>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>>>>> >> >
>>>>> >> > I recently run into this odd problem, and it is very difficult to
>>>>> >> > reproduce. I did not explicitly enable the "implicit_cache" option
>>>>> >> > anywhere in my code. If I simply remove the build folder and then
>>>>> >> > re-build everything works as normal. the problem happens when
>>>>> there is
>>>>> >> > a old build, and then I pulled in some new code where this
>>>>> "test.c"
>>>>> >> > has included an additional header io.h and scons seems not
>>>>> re-scanning
>>>>> >> > the file by default.
>>>>> >> >
>>>>> >> > I am using scons 3.0.1, is the implict_cache by default enabled
>>>>> there
>>>>> >> > and I have to disable it manually?
>>>>> >> >
>>>>> >> > Thanks,
>>>>> >> > Yanghao Hua
>>>>> >> _______________________________________________
>>>>> >> Scons-users mailing list
>>>>> >> Scons-***@scons.org
>>>>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>> >
>>>>> > _______________________________________________
>>>>> > Scons-users mailing list
>>>>> > Scons-***@scons.org
>>>>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-***@scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-***@scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-***@scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Hua Yanghao]

Hi Bill,
Sorry I missed that one.

The full command line when hit the failure:
gcc -o build/configs/pangu/usw/firmware/arch/pangu/test.os -c -g -Wall
-Werror -include config.h -Wno-error=main -Wno-main -Wno-format-security
-Wno-format -std=gnu99 -D_USW_FLAGS_TEST_0 -D_USW_FLAGS_TEST_1
-D_USW_FLAGS_TEST_2 -fPIC -Ibuild/configs/pangu/usw/config
-Ibuild/configs/pangu/usw/firmware/arch/pangu/include
-Ibuild/configs/pangu/usw/firmware/include
-Ibuild/configs/pangu/usw/firmware/arch/include
-Ibuild/configs/pangu/usw/firmware/common/include
-Ibuild/configs/pangu/usw/firmware/lib/cmd/include
-Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
-Ibuild/configs/pangu/usw/firmware/lib/fio/include
-Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
-Ibuild/configs/pangu/usw/firmware/test/example/include
-Ibuild/configs/pangu/usw/firmware/test/console/include
-Ibuild/configs/pangu/usw/firmware/boards/include
-Ibuild/configs/pangu/usw/firmware/boards/pangu/include
-Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
-Ibuild/configs/pangu/usw/config
-Ibuild/configs/pangu/usw/firmware/arch/pangu/include
-Ibuild/configs/pangu/usw/firmware/include
-Ibuild/configs/pangu/usw/firmware/arch/include
-Ibuild/configs/pangu/usw/firmware/common/include
-Ibuild/configs/pangu/usw/firmware/lib/cmd/include
-Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
-Ibuild/configs/pangu/usw/firmware/lib/fio/include
-Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
-Ibuild/configs/pangu/usw/firmware/test/example/include
-Ibuild/configs/pangu/usw/firmware/test/console/include
-Ibuild/configs/pangu/usw/firmware/boards/include
-Ibuild/configs/pangu/usw/firmware/boards/pangu/include
-Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
build/configs/pangu/usw/firmware/arch/pangu/test.c

And my CPPPATH seems also matching the command line:
['/home/hua/git/usw/build/configs/pangu/usw/config',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include',
'/home/hua/git/usw/build/configs/pangu/usw/config',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
'/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include']

Note the firmware/include is in both command line and CPPPATH, that's where
my io.h is located.

Best Regards,
Yanghao


On Tue, Oct 16, 2018 at 8:07 PM Bill Deegan <***@baddogconsulting.com>
wrote:

> You've still not replied with the compile command line.
> Also what's your CPPPATH?
>
>
> On Tue, Oct 16, 2018 at 1:25 PM Hua Yanghao <***@gmail.com> wrote:
>
>> it is the correct path and io.h is actually duplicated from
>> firmware/include/io.h
>>
>> On Tue 16. Oct 2018 at 17:34, Bill Deegan <***@baddogconsulting.com>
>> wrote:
>>
>>> Is `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' the
>>> correct path to io.h?
>>> Are you using duplicate=0, or not specifying in you SConscript()?
>>> Are you using chdir somewhere in your SCons logic?
>>>
>>> Also, please paste the compile line for the compile which should find
>>> io.h when it's passing?
>>>
>>> On Tue, Oct 16, 2018 at 11:14 AM Hua Yanghao <***@gmail.com>
>>> wrote:
>>>
>>>> no it is static file.
>>>>
>>>> On Tue 16. Oct 2018 at 17:08, Bill Deegan <***@baddogconsulting.com>
>>>> wrote:
>>>>
>>>>> Is io.h a generated file?
>>>>> Paste the compile line for the compile which should find io.h when
>>>>> it's passing?
>>>>>
>>>>>
>>>>> On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <***@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Bill,
>>>>>> Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
>>>>>> SConscript files. So normally all used header files will end up in the
>>>>>> build folder too. But occasionally scons seems missed it. I am
>>>>>> struggling to reproduce it ...
>>>>>>
>>>>>> BR, Yanghao
>>>>>> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <
>>>>>> ***@baddogconsulting.com> wrote:
>>>>>> >
>>>>>> > Yes. Headers are scanned recursively.
>>>>>> > Implicit cache should only be enable by command line flag or
>>>>>> SetOption()
>>>>>> >
>>>>>> > Where is io.h located? is it in your CPPPATH?
>>>>>> >
>>>>>> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <***@gmail.com>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> By the way, is scons scanner scans C file headers recursively?
>>>>>> Thanks.
>>>>>> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <***@gmail.com>
>>>>>> wrote:
>>>>>> >> >
>>>>>> >> > scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>>>>>> >> > Implicit dependency
>>>>>> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not
>>>>>> found,
>>>>>> >> > needed by target
>>>>>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>>>>>> >> >
>>>>>> >> > I recently run into this odd problem, and it is very difficult to
>>>>>> >> > reproduce. I did not explicitly enable the "implicit_cache"
>>>>>> option
>>>>>> >> > anywhere in my code. If I simply remove the build folder and then
>>>>>> >> > re-build everything works as normal. the problem happens when
>>>>>> there is
>>>>>> >> > a old build, and then I pulled in some new code where this
>>>>>> "test.c"
>>>>>> >> > has included an additional header io.h and scons seems not
>>>>>> re-scanning
>>>>>> >> > the file by default.
>>>>>> >> >
>>>>>> >> > I am using scons 3.0.1, is the implict_cache by default enabled
>>>>>> there
>>>>>> >> > and I have to disable it manually?
>>>>>> >> >
>>>>>> >> > Thanks,
>>>>>> >> > Yanghao Hua
>>>>>> >> _______________________________________________
>>>>>> >> Scons-users mailing list
>>>>>> >> Scons-***@scons.org
>>>>>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > Scons-users mailing list
>>>>>> > Scons-***@scons.org
>>>>>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-***@scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-***@scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-***@scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-***@scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Bill Deegan]

Try running with

--taskmastertrace=trace.log

You'll get a pretty verbose log there, and search for io.h it should show
more information about what's happening.

Is io.h included via "-include config.h" ?

-Bill

On Tue, Oct 16, 2018 at 5:01 PM Hua Yanghao <***@gmail.com> wrote:

> Hi Bill,
> Sorry I missed that one.
>
> The full command line when hit the failure:
> gcc -o build/configs/pangu/usw/firmware/arch/pangu/test.os -c -g -Wall
> -Werror -include config.h -Wno-error=main -Wno-main -Wno-format-security
> -Wno-format -std=gnu99 -D_USW_FLAGS_TEST_0 -D_USW_FLAGS_TEST_1
> -D_USW_FLAGS_TEST_2 -fPIC -Ibuild/configs/pangu/usw/config
> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
> -Ibuild/configs/pangu/usw/firmware/include
> -Ibuild/configs/pangu/usw/firmware/arch/include
> -Ibuild/configs/pangu/usw/firmware/common/include
> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
> -Ibuild/configs/pangu/usw/firmware/test/example/include
> -Ibuild/configs/pangu/usw/firmware/test/console/include
> -Ibuild/configs/pangu/usw/firmware/boards/include
> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
> -Ibuild/configs/pangu/usw/config
> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
> -Ibuild/configs/pangu/usw/firmware/include
> -Ibuild/configs/pangu/usw/firmware/arch/include
> -Ibuild/configs/pangu/usw/firmware/common/include
> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
> -Ibuild/configs/pangu/usw/firmware/test/example/include
> -Ibuild/configs/pangu/usw/firmware/test/console/include
> -Ibuild/configs/pangu/usw/firmware/boards/include
> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
> build/configs/pangu/usw/firmware/arch/pangu/test.c
>
> And my CPPPATH seems also matching the command line:
> ['/home/hua/git/usw/build/configs/pangu/usw/config',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include',
> '/home/hua/git/usw/build/configs/pangu/usw/config',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include']
>
> Note the firmware/include is in both command line and CPPPATH, that's
> where my io.h is located.
>
> Best Regards,
> Yanghao
>
>
> On Tue, Oct 16, 2018 at 8:07 PM Bill Deegan <***@baddogconsulting.com>
> wrote:
>
>> You've still not replied with the compile command line.
>> Also what's your CPPPATH?
>>
>>
>> On Tue, Oct 16, 2018 at 1:25 PM Hua Yanghao <***@gmail.com> wrote:
>>
>>> it is the correct path and io.h is actually duplicated from
>>> firmware/include/io.h
>>>
>>> On Tue 16. Oct 2018 at 17:34, Bill Deegan <***@baddogconsulting.com>
>>> wrote:
>>>
>>>> Is `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' the
>>>> correct path to io.h?
>>>> Are you using duplicate=0, or not specifying in you SConscript()?
>>>> Are you using chdir somewhere in your SCons logic?
>>>>
>>>> Also, please paste the compile line for the compile which should find
>>>> io.h when it's passing?
>>>>
>>>> On Tue, Oct 16, 2018 at 11:14 AM Hua Yanghao <***@gmail.com>
>>>> wrote:
>>>>
>>>>> no it is static file.
>>>>>
>>>>> On Tue 16. Oct 2018 at 17:08, Bill Deegan <***@baddogconsulting.com>
>>>>> wrote:
>>>>>
>>>>>> Is io.h a generated file?
>>>>>> Paste the compile line for the compile which should find io.h when
>>>>>> it's passing?
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <***@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Bill,
>>>>>>> Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
>>>>>>> SConscript files. So normally all used header files will end up in
>>>>>>> the
>>>>>>> build folder too. But occasionally scons seems missed it. I am
>>>>>>> struggling to reproduce it ...
>>>>>>>
>>>>>>> BR, Yanghao
>>>>>>> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <
>>>>>>> ***@baddogconsulting.com> wrote:
>>>>>>> >
>>>>>>> > Yes. Headers are scanned recursively.
>>>>>>> > Implicit cache should only be enable by command line flag or
>>>>>>> SetOption()
>>>>>>> >
>>>>>>> > Where is io.h located? is it in your CPPPATH?
>>>>>>> >
>>>>>>> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <***@gmail.com>
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >> By the way, is scons scanner scans C file headers recursively?
>>>>>>> Thanks.
>>>>>>> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <
>>>>>>> ***@gmail.com> wrote:
>>>>>>> >> >
>>>>>>> >> > scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>>>>>>> >> > Implicit dependency
>>>>>>> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not
>>>>>>> found,
>>>>>>> >> > needed by target
>>>>>>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>>>>>>> >> >
>>>>>>> >> > I recently run into this odd problem, and it is very difficult
>>>>>>> to
>>>>>>> >> > reproduce. I did not explicitly enable the "implicit_cache"
>>>>>>> option
>>>>>>> >> > anywhere in my code. If I simply remove the build folder and
>>>>>>> then
>>>>>>> >> > re-build everything works as normal. the problem happens when
>>>>>>> there is
>>>>>>> >> > a old build, and then I pulled in some new code where this
>>>>>>> "test.c"
>>>>>>> >> > has included an additional header io.h and scons seems not
>>>>>>> re-scanning
>>>>>>> >> > the file by default.
>>>>>>> >> >
>>>>>>> >> > I am using scons 3.0.1, is the implict_cache by default enabled
>>>>>>> there
>>>>>>> >> > and I have to disable it manually?
>>>>>>> >> >
>>>>>>> >> > Thanks,
>>>>>>> >> > Yanghao Hua
>>>>>>> >> _______________________________________________
>>>>>>> >> Scons-users mailing list
>>>>>>> >> Scons-***@scons.org
>>>>>>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>> >
>>>>>>> > _______________________________________________
>>>>>>> > Scons-users mailing list
>>>>>>> > Scons-***@scons.org
>>>>>>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>> _______________________________________________
>>>>>>> Scons-users mailing list
>>>>>>> Scons-***@scons.org
>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-***@scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-***@scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-***@scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-***@scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Hua Yanghao]

Config.h does not include any other headers. And the problem is it is not
easily reproducible. However once it happens it is sticky. I will try
harder tomorrow and get back to you. Thanks.

On Tue 16. Oct 2018 at 23:06, Bill Deegan <***@baddogconsulting.com> wrote:

> Try running with
>
> --taskmastertrace=trace.log
>
> You'll get a pretty verbose log there, and search for io.h it should show
> more information about what's happening.
>
> Is io.h included via "-include config.h" ?
>
> -Bill
>
> On Tue, Oct 16, 2018 at 5:01 PM Hua Yanghao <***@gmail.com> wrote:
>
>> Hi Bill,
>> Sorry I missed that one.
>>
>> The full command line when hit the failure:
>> gcc -o build/configs/pangu/usw/firmware/arch/pangu/test.os -c -g -Wall
>> -Werror -include config.h -Wno-error=main -Wno-main -Wno-format-security
>> -Wno-format -std=gnu99 -D_USW_FLAGS_TEST_0 -D_USW_FLAGS_TEST_1
>> -D_USW_FLAGS_TEST_2 -fPIC -Ibuild/configs/pangu/usw/config
>> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
>> -Ibuild/configs/pangu/usw/firmware/include
>> -Ibuild/configs/pangu/usw/firmware/arch/include
>> -Ibuild/configs/pangu/usw/firmware/common/include
>> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
>> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
>> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
>> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
>> -Ibuild/configs/pangu/usw/firmware/test/example/include
>> -Ibuild/configs/pangu/usw/firmware/test/console/include
>> -Ibuild/configs/pangu/usw/firmware/boards/include
>> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
>> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
>> -Ibuild/configs/pangu/usw/config
>> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
>> -Ibuild/configs/pangu/usw/firmware/include
>> -Ibuild/configs/pangu/usw/firmware/arch/include
>> -Ibuild/configs/pangu/usw/firmware/common/include
>> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
>> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
>> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
>> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
>> -Ibuild/configs/pangu/usw/firmware/test/example/include
>> -Ibuild/configs/pangu/usw/firmware/test/console/include
>> -Ibuild/configs/pangu/usw/firmware/boards/include
>> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
>> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
>> build/configs/pangu/usw/firmware/arch/pangu/test.c
>>
>> And my CPPPATH seems also matching the command line:
>> ['/home/hua/git/usw/build/configs/pangu/usw/config',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/config',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include']
>>
>> Note the firmware/include is in both command line and CPPPATH, that's
>> where my io.h is located.
>>
>> Best Regards,
>> Yanghao
>>
>>
>> On Tue, Oct 16, 2018 at 8:07 PM Bill Deegan <***@baddogconsulting.com>
>> wrote:
>>
>>> You've still not replied with the compile command line.
>>> Also what's your CPPPATH?
>>>
>>>
>>> On Tue, Oct 16, 2018 at 1:25 PM Hua Yanghao <***@gmail.com>
>>> wrote:
>>>
>>>> it is the correct path and io.h is actually duplicated from
>>>> firmware/include/io.h
>>>>
>>>> On Tue 16. Oct 2018 at 17:34, Bill Deegan <***@baddogconsulting.com>
>>>> wrote:
>>>>
>>>>> Is `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' the
>>>>> correct path to io.h?
>>>>> Are you using duplicate=0, or not specifying in you SConscript()?
>>>>> Are you using chdir somewhere in your SCons logic?
>>>>>
>>>>> Also, please paste the compile line for the compile which should find
>>>>> io.h when it's passing?
>>>>>
>>>>> On Tue, Oct 16, 2018 at 11:14 AM Hua Yanghao <***@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> no it is static file.
>>>>>>
>>>>>> On Tue 16. Oct 2018 at 17:08, Bill Deegan <***@baddogconsulting.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Is io.h a generated file?
>>>>>>> Paste the compile line for the compile which should find io.h when
>>>>>>> it's passing?
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <***@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Bill,
>>>>>>>> Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
>>>>>>>> SConscript files. So normally all used header files will end up in
>>>>>>>> the
>>>>>>>> build folder too. But occasionally scons seems missed it. I am
>>>>>>>> struggling to reproduce it ...
>>>>>>>>
>>>>>>>> BR, Yanghao
>>>>>>>> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <
>>>>>>>> ***@baddogconsulting.com> wrote:
>>>>>>>> >
>>>>>>>> > Yes. Headers are scanned recursively.
>>>>>>>> > Implicit cache should only be enable by command line flag or
>>>>>>>> SetOption()
>>>>>>>> >
>>>>>>>> > Where is io.h located? is it in your CPPPATH?
>>>>>>>> >
>>>>>>>> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <***@gmail.com>
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>> >> By the way, is scons scanner scans C file headers recursively?
>>>>>>>> Thanks.
>>>>>>>> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <
>>>>>>>> ***@gmail.com> wrote:
>>>>>>>> >> >
>>>>>>>> >> > scons: ***
>>>>>>>> [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>>>>>>>> >> > Implicit dependency
>>>>>>>> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not
>>>>>>>> found,
>>>>>>>> >> > needed by target
>>>>>>>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>>>>>>>> >> >
>>>>>>>> >> > I recently run into this odd problem, and it is very difficult
>>>>>>>> to
>>>>>>>> >> > reproduce. I did not explicitly enable the "implicit_cache"
>>>>>>>> option
>>>>>>>> >> > anywhere in my code. If I simply remove the build folder and
>>>>>>>> then
>>>>>>>> >> > re-build everything works as normal. the problem happens when
>>>>>>>> there is
>>>>>>>> >> > a old build, and then I pulled in some new code where this
>>>>>>>> "test.c"
>>>>>>>> >> > has included an additional header io.h and scons seems not
>>>>>>>> re-scanning
>>>>>>>> >> > the file by default.
>>>>>>>> >> >
>>>>>>>> >> > I am using scons 3.0.1, is the implict_cache by default
>>>>>>>> enabled there
>>>>>>>> >> > and I have to disable it manually?
>>>>>>>> >> >
>>>>>>>> >> > Thanks,
>>>>>>>> >> > Yanghao Hua
>>>>>>>> >> _______________________________________________
>>>>>>>> >> Scons-users mailing list
>>>>>>>> >> Scons-***@scons.org
>>>>>>>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > Scons-users mailing list
>>>>>>>> > Scons-***@scons.org
>>>>>>>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>> _______________________________________________
>>>>>>>> Scons-users mailing list
>>>>>>>> Scons-***@scons.org
>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Scons-users mailing list
>>>>>>> Scons-***@scons.org
>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-***@scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-***@scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-***@scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-***@scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Hua Yanghao]

I finally reproduced this issue, however this --taskmastertrace=trace.log
the compilation passes instead of failing. Thoughts?

***@huyangha-mobl:~/git/usw-abc $ ./run configs/pangu.py
Running : ./tools/scons -Q config=configs/pangu.py
INFO: Processing target usw ... Done.
INFO: usw_config completed in 0.19 seconds.
__CONFIG build/configs/pangu/usw/config/config.h
____SHCC build/configs/pangu/usw/firmware/arch/weak.os
______AR build/configs/pangu/usw/firmware/arch/libdefault.o
__RANLIB build/configs/pangu/usw/firmware/arch/libdefault.o
____SHCC build/configs/pangu/usw/firmware/arch/pangu/lib.os
____SHCC build/configs/pangu/usw/firmware/arch/pangu/main.os
scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os] Implicit
dependency `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not
found, needed by target
`build/configs/pangu/usw/firmware/arch/pangu/test.os'.
***@huyangha-mobl:~/git/usw-abc $ ./run configs/pangu.py
--taskmastertrace=trace.log
Running : ./tools/scons -Q config=configs/pangu.py
--taskmastertrace=trace.log
INFO: Processing target usw ... Done.
INFO: usw_config completed in 0.21 seconds.
__CONFIG build/configs/pangu/usw/config/config.h
____SHCC build/configs/pangu/usw/firmware/arch/pangu/test.os
____SHCC build/configs/pangu/usw/firmware/boards/weak.os
______AR build/configs/pangu/usw/firmware/boards/libdefault.o
__RANLIB build/configs/pangu/usw/firmware/boards/libdefault.o
____SHCC build/configs/pangu/usw/firmware/boards/pangu/board.os
____SHCC build/configs/pangu/usw/firmware/common/cpu.os
____SHCC build/configs/pangu/usw/firmware/common/weak.os
____SHCC build/configs/pangu/usw/firmware/common/log.os
______AR build/configs/pangu/usw/firmware/common/libdefault.o
__RANLIB build/configs/pangu/usw/firmware/common/libdefault.o
____SHCC build/configs/pangu/usw/firmware/common/main.os
____SHCC build/configs/pangu/usw/firmware/drivers/pcie/dwc_ep.os
______AR build/configs/pangu/usw/firmware/drivers/pcie/libdefault.o
__RANLIB build/configs/pangu/usw/firmware/drivers/pcie/libdefault.o
____SHCC build/configs/pangu/usw/firmware/lib/cmd/cmd.os
____SHCC build/configs/pangu/usw/firmware/lib/cmd/test.os
____SHCC build/configs/pangu/usw/firmware/lib/fio/cmd.os
____SHCC build/configs/pangu/usw/firmware/lib/fio/usw_device.os
____SHCC build/configs/pangu/usw/firmware/lib/fio/linux64_device.os
______AR build/configs/pangu/usw/firmware/lib/fio/libdefault.o
__RANLIB build/configs/pangu/usw/firmware/lib/fio/libdefault.o
____SHCC
build/configs/pangu/usw/firmware/lib/simple_console/simple_console.os
______AR build/configs/pangu/usw/firmware/lib/simple_console/libdefault.o
__RANLIB build/configs/pangu/usw/firmware/lib/simple_console/libdefault.o
____SHCC build/configs/pangu/usw/firmware/lib/simple_pipe/connect.os
____SHCC build/configs/pangu/usw/firmware/lib/simple_pipe/pipe.os
______AR build/configs/pangu/usw/firmware/lib/simple_pipe/libdefault.o
__RANLIB build/configs/pangu/usw/firmware/lib/simple_pipe/libdefault.o
____SHCC build/configs/pangu/usw/firmware/test/console/hello.os
____SHCC build/configs/pangu/usw/firmware/test/console/test.os
____SHCC build/configs/pangu/usw/firmware/test/example/test.os
____SHLD build/configs/pangu/usw/libusw.so
_USWHASH build/configs/pangu/usw/libusw.so
_USWHASH build/configs/pangu/usw/libusw.so --> Changed
***@huyangha-mobl:~/git/usw-abc $

On Tue, Oct 16, 2018 at 11:10 PM Hua Yanghao <***@gmail.com> wrote:

> Config.h does not include any other headers. And the problem is it is not
> easily reproducible. However once it happens it is sticky. I will try
> harder tomorrow and get back to you. Thanks.
>
> On Tue 16. Oct 2018 at 23:06, Bill Deegan <***@baddogconsulting.com>
> wrote:
>
>> Try running with
>>
>> --taskmastertrace=trace.log
>>
>> You'll get a pretty verbose log there, and search for io.h it should show
>> more information about what's happening.
>>
>> Is io.h included via "-include config.h" ?
>>
>> -Bill
>>
>> On Tue, Oct 16, 2018 at 5:01 PM Hua Yanghao <***@gmail.com> wrote:
>>
>>> Hi Bill,
>>> Sorry I missed that one.
>>>
>>> The full command line when hit the failure:
>>> gcc -o build/configs/pangu/usw/firmware/arch/pangu/test.os -c -g -Wall
>>> -Werror -include config.h -Wno-error=main -Wno-main -Wno-format-security
>>> -Wno-format -std=gnu99 -D_USW_FLAGS_TEST_0 -D_USW_FLAGS_TEST_1
>>> -D_USW_FLAGS_TEST_2 -fPIC -Ibuild/configs/pangu/usw/config
>>> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
>>> -Ibuild/configs/pangu/usw/firmware/include
>>> -Ibuild/configs/pangu/usw/firmware/arch/include
>>> -Ibuild/configs/pangu/usw/firmware/common/include
>>> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
>>> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
>>> -Ibuild/configs/pangu/usw/firmware/test/example/include
>>> -Ibuild/configs/pangu/usw/firmware/test/console/include
>>> -Ibuild/configs/pangu/usw/firmware/boards/include
>>> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
>>> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
>>> -Ibuild/configs/pangu/usw/config
>>> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
>>> -Ibuild/configs/pangu/usw/firmware/include
>>> -Ibuild/configs/pangu/usw/firmware/arch/include
>>> -Ibuild/configs/pangu/usw/firmware/common/include
>>> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
>>> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
>>> -Ibuild/configs/pangu/usw/firmware/test/example/include
>>> -Ibuild/configs/pangu/usw/firmware/test/console/include
>>> -Ibuild/configs/pangu/usw/firmware/boards/include
>>> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
>>> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
>>> build/configs/pangu/usw/firmware/arch/pangu/test.c
>>>
>>> And my CPPPATH seems also matching the command line:
>>> ['/home/hua/git/usw/build/configs/pangu/usw/config',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/config',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include']
>>>
>>> Note the firmware/include is in both command line and CPPPATH, that's
>>> where my io.h is located.
>>>
>>> Best Regards,
>>> Yanghao
>>>
>>>
>>> On Tue, Oct 16, 2018 at 8:07 PM Bill Deegan <***@baddogconsulting.com>
>>> wrote:
>>>
>>>> You've still not replied with the compile command line.
>>>> Also what's your CPPPATH?
>>>>
>>>>
>>>> On Tue, Oct 16, 2018 at 1:25 PM Hua Yanghao <***@gmail.com>
>>>> wrote:
>>>>
>>>>> it is the correct path and io.h is actually duplicated from
>>>>> firmware/include/io.h
>>>>>
>>>>> On Tue 16. Oct 2018 at 17:34, Bill Deegan <***@baddogconsulting.com>
>>>>> wrote:
>>>>>
>>>>>> Is `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' the
>>>>>> correct path to io.h?
>>>>>> Are you using duplicate=0, or not specifying in you SConscript()?
>>>>>> Are you using chdir somewhere in your SCons logic?
>>>>>>
>>>>>> Also, please paste the compile line for the compile which should find
>>>>>> io.h when it's passing?
>>>>>>
>>>>>> On Tue, Oct 16, 2018 at 11:14 AM Hua Yanghao <***@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> no it is static file.
>>>>>>>
>>>>>>> On Tue 16. Oct 2018 at 17:08, Bill Deegan <***@baddogconsulting.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Is io.h a generated file?
>>>>>>>> Paste the compile line for the compile which should find io.h when
>>>>>>>> it's passing?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <***@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Bill,
>>>>>>>>> Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
>>>>>>>>> SConscript files. So normally all used header files will end up in
>>>>>>>>> the
>>>>>>>>> build folder too. But occasionally scons seems missed it. I am
>>>>>>>>> struggling to reproduce it ...
>>>>>>>>>
>>>>>>>>> BR, Yanghao
>>>>>>>>> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <
>>>>>>>>> ***@baddogconsulting.com> wrote:
>>>>>>>>> >
>>>>>>>>> > Yes. Headers are scanned recursively.
>>>>>>>>> > Implicit cache should only be enable by command line flag or
>>>>>>>>> SetOption()
>>>>>>>>> >
>>>>>>>>> > Where is io.h located? is it in your CPPPATH?
>>>>>>>>> >
>>>>>>>>> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <
>>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>> >>
>>>>>>>>> >> By the way, is scons scanner scans C file headers recursively?
>>>>>>>>> Thanks.
>>>>>>>>> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <
>>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>> >> >
>>>>>>>>> >> > scons: ***
>>>>>>>>> [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>>>>>>>>> >> > Implicit dependency
>>>>>>>>> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h'
>>>>>>>>> not found,
>>>>>>>>> >> > needed by target
>>>>>>>>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>>>>>>>>> >> >
>>>>>>>>> >> > I recently run into this odd problem, and it is very
>>>>>>>>> difficult to
>>>>>>>>> >> > reproduce. I did not explicitly enable the "implicit_cache"
>>>>>>>>> option
>>>>>>>>> >> > anywhere in my code. If I simply remove the build folder and
>>>>>>>>> then
>>>>>>>>> >> > re-build everything works as normal. the problem happens when
>>>>>>>>> there is
>>>>>>>>> >> > a old build, and then I pulled in some new code where this
>>>>>>>>> "test.c"
>>>>>>>>> >> > has included an additional header io.h and scons seems not
>>>>>>>>> re-scanning
>>>>>>>>> >> > the file by default.
>>>>>>>>> >> >
>>>>>>>>> >> > I am using scons 3.0.1, is the implict_cache by default
>>>>>>>>> enabled there
>>>>>>>>> >> > and I have to disable it manually?
>>>>>>>>> >> >
>>>>>>>>> >> > Thanks,
>>>>>>>>> >> > Yanghao Hua
>>>>>>>>> >> _______________________________________________
>>>>>>>>> >> Scons-users mailing list
>>>>>>>>> >> Scons-***@scons.org
>>>>>>>>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>> >
>>>>>>>>> > _______________________________________________
>>>>>>>>> > Scons-users mailing list
>>>>>>>>> > Scons-***@scons.org
>>>>>>>>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>> _______________________________________________
>>>>>>>>> Scons-users mailing list
>>>>>>>>> Scons-***@scons.org
>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Scons-users mailing list
>>>>>>>> Scons-***@scons.org
>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Scons-users mailing list
>>>>>>> Scons-***@scons.org
>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-***@scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-***@scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-***@scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-***@scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>

[Hua Yanghao]

It looks like this time even though I reproduced the issue it is not really
sticky and always passes on a second run.
I have re-run with the trace: https://pastebin.com/2ziqM4ri

The part that is important is there is one file, e.g. included <io.h>, and
in one version io.h is in folder A/io.h. And then there is a restructure of
file and io.h moved to folder B/io.h.
Folder A is in search path at commit X, build pass. Folder B is in search
path at commit Y, build pass too.

However if you first build on commit X (pass) and then switch to commit Y
and build again, it fails like above.

@Bill Deegan <***@baddogconsulting.com> please help to take a look the
trace file and let me know if more experiment I can do. At least now I can
reproduce it reliably on-demand.

On Wed, Oct 17, 2018 at 10:06 PM Hua Yanghao <***@gmail.com> wrote:

> I finally reproduced this issue, however this --taskmastertrace=trace.log
> the compilation passes instead of failing. Thoughts?
>
> ***@huyangha-mobl:~/git/usw-abc $ ./run configs/pangu.py
> Running : ./tools/scons -Q config=configs/pangu.py
> INFO: Processing target usw ... Done.
> INFO: usw_config completed in 0.19 seconds.
> __CONFIG build/configs/pangu/usw/config/config.h
> ____SHCC build/configs/pangu/usw/firmware/arch/weak.os
> ______AR build/configs/pangu/usw/firmware/arch/libdefault.o
> __RANLIB build/configs/pangu/usw/firmware/arch/libdefault.o
> ____SHCC build/configs/pangu/usw/firmware/arch/pangu/lib.os
> ____SHCC build/configs/pangu/usw/firmware/arch/pangu/main.os
> scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os] Implicit
> dependency `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not
> found, needed by target
> `build/configs/pangu/usw/firmware/arch/pangu/test.os'.
> ***@huyangha-mobl:~/git/usw-abc $ ./run configs/pangu.py
> --taskmastertrace=trace.log
> Running : ./tools/scons -Q config=configs/pangu.py
> --taskmastertrace=trace.log
> INFO: Processing target usw ... Done.
> INFO: usw_config completed in 0.21 seconds.
> __CONFIG build/configs/pangu/usw/config/config.h
> ____SHCC build/configs/pangu/usw/firmware/arch/pangu/test.os
> ____SHCC build/configs/pangu/usw/firmware/boards/weak.os
> ______AR build/configs/pangu/usw/firmware/boards/libdefault.o
> __RANLIB build/configs/pangu/usw/firmware/boards/libdefault.o
> ____SHCC build/configs/pangu/usw/firmware/boards/pangu/board.os
> ____SHCC build/configs/pangu/usw/firmware/common/cpu.os
> ____SHCC build/configs/pangu/usw/firmware/common/weak.os
> ____SHCC build/configs/pangu/usw/firmware/common/log.os
> ______AR build/configs/pangu/usw/firmware/common/libdefault.o
> __RANLIB build/configs/pangu/usw/firmware/common/libdefault.o
> ____SHCC build/configs/pangu/usw/firmware/common/main.os
> ____SHCC build/configs/pangu/usw/firmware/drivers/pcie/dwc_ep.os
> ______AR build/configs/pangu/usw/firmware/drivers/pcie/libdefault.o
> __RANLIB build/configs/pangu/usw/firmware/drivers/pcie/libdefault.o
> ____SHCC build/configs/pangu/usw/firmware/lib/cmd/cmd.os
> ____SHCC build/configs/pangu/usw/firmware/lib/cmd/test.os
> ____SHCC build/configs/pangu/usw/firmware/lib/fio/cmd.os
> ____SHCC build/configs/pangu/usw/firmware/lib/fio/usw_device.os
> ____SHCC build/configs/pangu/usw/firmware/lib/fio/linux64_device.os
> ______AR build/configs/pangu/usw/firmware/lib/fio/libdefault.o
> __RANLIB build/configs/pangu/usw/firmware/lib/fio/libdefault.o
> ____SHCC
> build/configs/pangu/usw/firmware/lib/simple_console/simple_console.os
> ______AR build/configs/pangu/usw/firmware/lib/simple_console/libdefault.o
> __RANLIB build/configs/pangu/usw/firmware/lib/simple_console/libdefault.o
> ____SHCC build/configs/pangu/usw/firmware/lib/simple_pipe/connect.os
> ____SHCC build/configs/pangu/usw/firmware/lib/simple_pipe/pipe.os
> ______AR build/configs/pangu/usw/firmware/lib/simple_pipe/libdefault.o
> __RANLIB build/configs/pangu/usw/firmware/lib/simple_pipe/libdefault.o
> ____SHCC build/configs/pangu/usw/firmware/test/console/hello.os
> ____SHCC build/configs/pangu/usw/firmware/test/console/test.os
> ____SHCC build/configs/pangu/usw/firmware/test/example/test.os
> ____SHLD build/configs/pangu/usw/libusw.so
> _USWHASH build/configs/pangu/usw/libusw.so
> _USWHASH build/configs/pangu/usw/libusw.so --> Changed
> ***@huyangha-mobl:~/git/usw-abc $
>
> On Tue, Oct 16, 2018 at 11:10 PM Hua Yanghao <***@gmail.com> wrote:
>
>> Config.h does not include any other headers. And the problem is it is not
>> easily reproducible. However once it happens it is sticky. I will try
>> harder tomorrow and get back to you. Thanks.
>>
>> On Tue 16. Oct 2018 at 23:06, Bill Deegan <***@baddogconsulting.com>
>> wrote:
>>
>>> Try running with
>>>
>>> --taskmastertrace=trace.log
>>>
>>> You'll get a pretty verbose log there, and search for io.h it should
>>> show more information about what's happening.
>>>
>>> Is io.h included via "-include config.h" ?
>>>
>>> -Bill
>>>
>>> On Tue, Oct 16, 2018 at 5:01 PM Hua Yanghao <***@gmail.com>
>>> wrote:
>>>
>>>> Hi Bill,
>>>> Sorry I missed that one.
>>>>
>>>> The full command line when hit the failure:
>>>> gcc -o build/configs/pangu/usw/firmware/arch/pangu/test.os -c -g -Wall
>>>> -Werror -include config.h -Wno-error=main -Wno-main -Wno-format-security
>>>> -Wno-format -std=gnu99 -D_USW_FLAGS_TEST_0 -D_USW_FLAGS_TEST_1
>>>> -D_USW_FLAGS_TEST_2 -fPIC -Ibuild/configs/pangu/usw/config
>>>> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
>>>> -Ibuild/configs/pangu/usw/firmware/include
>>>> -Ibuild/configs/pangu/usw/firmware/arch/include
>>>> -Ibuild/configs/pangu/usw/firmware/common/include
>>>> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
>>>> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
>>>> -Ibuild/configs/pangu/usw/firmware/test/example/include
>>>> -Ibuild/configs/pangu/usw/firmware/test/console/include
>>>> -Ibuild/configs/pangu/usw/firmware/boards/include
>>>> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
>>>> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
>>>> -Ibuild/configs/pangu/usw/config
>>>> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
>>>> -Ibuild/configs/pangu/usw/firmware/include
>>>> -Ibuild/configs/pangu/usw/firmware/arch/include
>>>> -Ibuild/configs/pangu/usw/firmware/common/include
>>>> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
>>>> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
>>>> -Ibuild/configs/pangu/usw/firmware/test/example/include
>>>> -Ibuild/configs/pangu/usw/firmware/test/console/include
>>>> -Ibuild/configs/pangu/usw/firmware/boards/include
>>>> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
>>>> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
>>>> build/configs/pangu/usw/firmware/arch/pangu/test.c
>>>>
>>>> And my CPPPATH seems also matching the command line:
>>>> ['/home/hua/git/usw/build/configs/pangu/usw/config',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/config',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include']
>>>>
>>>> Note the firmware/include is in both command line and CPPPATH, that's
>>>> where my io.h is located.
>>>>
>>>> Best Regards,
>>>> Yanghao
>>>>
>>>>
>>>> On Tue, Oct 16, 2018 at 8:07 PM Bill Deegan <***@baddogconsulting.com>
>>>> wrote:
>>>>
>>>>> You've still not replied with the compile command line.
>>>>> Also what's your CPPPATH?
>>>>>
>>>>>
>>>>> On Tue, Oct 16, 2018 at 1:25 PM Hua Yanghao <***@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> it is the correct path and io.h is actually duplicated from
>>>>>> firmware/include/io.h
>>>>>>
>>>>>> On Tue 16. Oct 2018 at 17:34, Bill Deegan <***@baddogconsulting.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Is `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' the
>>>>>>> correct path to io.h?
>>>>>>> Are you using duplicate=0, or not specifying in you SConscript()?
>>>>>>> Are you using chdir somewhere in your SCons logic?
>>>>>>>
>>>>>>> Also, please paste the compile line for the compile which should
>>>>>>> find io.h when it's passing?
>>>>>>>
>>>>>>> On Tue, Oct 16, 2018 at 11:14 AM Hua Yanghao <***@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> no it is static file.
>>>>>>>>
>>>>>>>> On Tue 16. Oct 2018 at 17:08, Bill Deegan <
>>>>>>>> ***@baddogconsulting.com> wrote:
>>>>>>>>
>>>>>>>>> Is io.h a generated file?
>>>>>>>>> Paste the compile line for the compile which should find io.h when
>>>>>>>>> it's passing?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <***@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Bill,
>>>>>>>>>> Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
>>>>>>>>>> SConscript files. So normally all used header files will end up
>>>>>>>>>> in the
>>>>>>>>>> build folder too. But occasionally scons seems missed it. I am
>>>>>>>>>> struggling to reproduce it ...
>>>>>>>>>>
>>>>>>>>>> BR, Yanghao
>>>>>>>>>> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <
>>>>>>>>>> ***@baddogconsulting.com> wrote:
>>>>>>>>>> >
>>>>>>>>>> > Yes. Headers are scanned recursively.
>>>>>>>>>> > Implicit cache should only be enable by command line flag or
>>>>>>>>>> SetOption()
>>>>>>>>>> >
>>>>>>>>>> > Where is io.h located? is it in your CPPPATH?
>>>>>>>>>> >
>>>>>>>>>> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <
>>>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>>> >>
>>>>>>>>>> >> By the way, is scons scanner scans C file headers recursively?
>>>>>>>>>> Thanks.
>>>>>>>>>> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <
>>>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>>> >> >
>>>>>>>>>> >> > scons: ***
>>>>>>>>>> [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>>>>>>>>>> >> > Implicit dependency
>>>>>>>>>> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h'
>>>>>>>>>> not found,
>>>>>>>>>> >> > needed by target
>>>>>>>>>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>>>>>>>>>> >> >
>>>>>>>>>> >> > I recently run into this odd problem, and it is very
>>>>>>>>>> difficult to
>>>>>>>>>> >> > reproduce. I did not explicitly enable the "implicit_cache"
>>>>>>>>>> option
>>>>>>>>>> >> > anywhere in my code. If I simply remove the build folder and
>>>>>>>>>> then
>>>>>>>>>> >> > re-build everything works as normal. the problem happens
>>>>>>>>>> when there is
>>>>>>>>>> >> > a old build, and then I pulled in some new code where this
>>>>>>>>>> "test.c"
>>>>>>>>>> >> > has included an additional header io.h and scons seems not
>>>>>>>>>> re-scanning
>>>>>>>>>> >> > the file by default.
>>>>>>>>>> >> >
>>>>>>>>>> >> > I am using scons 3.0.1, is the implict_cache by default
>>>>>>>>>> enabled there
>>>>>>>>>> >> > and I have to disable it manually?
>>>>>>>>>> >> >
>>>>>>>>>> >> > Thanks,
>>>>>>>>>> >> > Yanghao Hua
>>>>>>>>>> >> _______________________________________________
>>>>>>>>>> >> Scons-users mailing list
>>>>>>>>>> >> Scons-***@scons.org
>>>>>>>>>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>> >
>>>>>>>>>> > _______________________________________________
>>>>>>>>>> > Scons-users mailing list
>>>>>>>>>> > Scons-***@scons.org
>>>>>>>>>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Scons-users mailing list
>>>>>>>>>> Scons-***@scons.org
>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Scons-users mailing list
>>>>>>>>> Scons-***@scons.org
>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Scons-users mailing list
>>>>>>>> Scons-***@scons.org
>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Scons-users mailing list
>>>>>>> Scons-***@scons.org
>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-***@scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-***@scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-***@scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-***@scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>>

[Hua Yanghao]

However, if on commit Y you do a clean and re-build, everything passes.
Seems some cached state is in play here?

On Wed, Oct 17, 2018 at 10:35 PM Hua Yanghao <***@gmail.com> wrote:

> It looks like this time even though I reproduced the issue it is not
> really sticky and always passes on a second run.
> I have re-run with the trace: https://pastebin.com/2ziqM4ri
>
> The part that is important is there is one file, e.g. included <io.h>, and
> in one version io.h is in folder A/io.h. And then there is a restructure of
> file and io.h moved to folder B/io.h.
> Folder A is in search path at commit X, build pass. Folder B is in search
> path at commit Y, build pass too.
>
> However if you first build on commit X (pass) and then switch to commit Y
> and build again, it fails like above.
>
> @Bill Deegan <***@baddogconsulting.com> please help to take a look the
> trace file and let me know if more experiment I can do. At least now I can
> reproduce it reliably on-demand.
>
> On Wed, Oct 17, 2018 at 10:06 PM Hua Yanghao <***@gmail.com> wrote:
>
>> I finally reproduced this issue, however this --taskmastertrace=trace.log
>> the compilation passes instead of failing. Thoughts?
>>
>> ***@huyangha-mobl:~/git/usw-abc $ ./run configs/pangu.py
>> Running : ./tools/scons -Q config=configs/pangu.py
>> INFO: Processing target usw ... Done.
>> INFO: usw_config completed in 0.19 seconds.
>> __CONFIG build/configs/pangu/usw/config/config.h
>> ____SHCC build/configs/pangu/usw/firmware/arch/weak.os
>> ______AR build/configs/pangu/usw/firmware/arch/libdefault.o
>> __RANLIB build/configs/pangu/usw/firmware/arch/libdefault.o
>> ____SHCC build/configs/pangu/usw/firmware/arch/pangu/lib.os
>> ____SHCC build/configs/pangu/usw/firmware/arch/pangu/main.os
>> scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os] Implicit
>> dependency `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not
>> found, needed by target
>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'.
>> ***@huyangha-mobl:~/git/usw-abc $ ./run configs/pangu.py
>> --taskmastertrace=trace.log
>> Running : ./tools/scons -Q config=configs/pangu.py
>> --taskmastertrace=trace.log
>> INFO: Processing target usw ... Done.
>> INFO: usw_config completed in 0.21 seconds.
>> __CONFIG build/configs/pangu/usw/config/config.h
>> ____SHCC build/configs/pangu/usw/firmware/arch/pangu/test.os
>> ____SHCC build/configs/pangu/usw/firmware/boards/weak.os
>> ______AR build/configs/pangu/usw/firmware/boards/libdefault.o
>> __RANLIB build/configs/pangu/usw/firmware/boards/libdefault.o
>> ____SHCC build/configs/pangu/usw/firmware/boards/pangu/board.os
>> ____SHCC build/configs/pangu/usw/firmware/common/cpu.os
>> ____SHCC build/configs/pangu/usw/firmware/common/weak.os
>> ____SHCC build/configs/pangu/usw/firmware/common/log.os
>> ______AR build/configs/pangu/usw/firmware/common/libdefault.o
>> __RANLIB build/configs/pangu/usw/firmware/common/libdefault.o
>> ____SHCC build/configs/pangu/usw/firmware/common/main.os
>> ____SHCC build/configs/pangu/usw/firmware/drivers/pcie/dwc_ep.os
>> ______AR build/configs/pangu/usw/firmware/drivers/pcie/libdefault.o
>> __RANLIB build/configs/pangu/usw/firmware/drivers/pcie/libdefault.o
>> ____SHCC build/configs/pangu/usw/firmware/lib/cmd/cmd.os
>> ____SHCC build/configs/pangu/usw/firmware/lib/cmd/test.os
>> ____SHCC build/configs/pangu/usw/firmware/lib/fio/cmd.os
>> ____SHCC build/configs/pangu/usw/firmware/lib/fio/usw_device.os
>> ____SHCC build/configs/pangu/usw/firmware/lib/fio/linux64_device.os
>> ______AR build/configs/pangu/usw/firmware/lib/fio/libdefault.o
>> __RANLIB build/configs/pangu/usw/firmware/lib/fio/libdefault.o
>> ____SHCC
>> build/configs/pangu/usw/firmware/lib/simple_console/simple_console.os
>> ______AR build/configs/pangu/usw/firmware/lib/simple_console/libdefault.o
>> __RANLIB build/configs/pangu/usw/firmware/lib/simple_console/libdefault.o
>> ____SHCC build/configs/pangu/usw/firmware/lib/simple_pipe/connect.os
>> ____SHCC build/configs/pangu/usw/firmware/lib/simple_pipe/pipe.os
>> ______AR build/configs/pangu/usw/firmware/lib/simple_pipe/libdefault.o
>> __RANLIB build/configs/pangu/usw/firmware/lib/simple_pipe/libdefault.o
>> ____SHCC build/configs/pangu/usw/firmware/test/console/hello.os
>> ____SHCC build/configs/pangu/usw/firmware/test/console/test.os
>> ____SHCC build/configs/pangu/usw/firmware/test/example/test.os
>> ____SHLD build/configs/pangu/usw/libusw.so
>> _USWHASH build/configs/pangu/usw/libusw.so
>> _USWHASH build/configs/pangu/usw/libusw.so --> Changed
>> ***@huyangha-mobl:~/git/usw-abc $
>>
>> On Tue, Oct 16, 2018 at 11:10 PM Hua Yanghao <***@gmail.com>
>> wrote:
>>
>>> Config.h does not include any other headers. And the problem is it is
>>> not easily reproducible. However once it happens it is sticky. I will try
>>> harder tomorrow and get back to you. Thanks.
>>>
>>> On Tue 16. Oct 2018 at 23:06, Bill Deegan <***@baddogconsulting.com>
>>> wrote:
>>>
>>>> Try running with
>>>>
>>>> --taskmastertrace=trace.log
>>>>
>>>> You'll get a pretty verbose log there, and search for io.h it should
>>>> show more information about what's happening.
>>>>
>>>> Is io.h included via "-include config.h" ?
>>>>
>>>> -Bill
>>>>
>>>> On Tue, Oct 16, 2018 at 5:01 PM Hua Yanghao <***@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Bill,
>>>>> Sorry I missed that one.
>>>>>
>>>>> The full command line when hit the failure:
>>>>> gcc -o build/configs/pangu/usw/firmware/arch/pangu/test.os -c -g -Wall
>>>>> -Werror -include config.h -Wno-error=main -Wno-main -Wno-format-security
>>>>> -Wno-format -std=gnu99 -D_USW_FLAGS_TEST_0 -D_USW_FLAGS_TEST_1
>>>>> -D_USW_FLAGS_TEST_2 -fPIC -Ibuild/configs/pangu/usw/config
>>>>> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
>>>>> -Ibuild/configs/pangu/usw/firmware/include
>>>>> -Ibuild/configs/pangu/usw/firmware/arch/include
>>>>> -Ibuild/configs/pangu/usw/firmware/common/include
>>>>> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
>>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
>>>>> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
>>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
>>>>> -Ibuild/configs/pangu/usw/firmware/test/example/include
>>>>> -Ibuild/configs/pangu/usw/firmware/test/console/include
>>>>> -Ibuild/configs/pangu/usw/firmware/boards/include
>>>>> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
>>>>> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
>>>>> -Ibuild/configs/pangu/usw/config
>>>>> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
>>>>> -Ibuild/configs/pangu/usw/firmware/include
>>>>> -Ibuild/configs/pangu/usw/firmware/arch/include
>>>>> -Ibuild/configs/pangu/usw/firmware/common/include
>>>>> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
>>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
>>>>> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
>>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
>>>>> -Ibuild/configs/pangu/usw/firmware/test/example/include
>>>>> -Ibuild/configs/pangu/usw/firmware/test/console/include
>>>>> -Ibuild/configs/pangu/usw/firmware/boards/include
>>>>> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
>>>>> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
>>>>> build/configs/pangu/usw/firmware/arch/pangu/test.c
>>>>>
>>>>> And my CPPPATH seems also matching the command line:
>>>>> ['/home/hua/git/usw/build/configs/pangu/usw/config',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/config',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include']
>>>>>
>>>>> Note the firmware/include is in both command line and CPPPATH, that's
>>>>> where my io.h is located.
>>>>>
>>>>> Best Regards,
>>>>> Yanghao
>>>>>
>>>>>
>>>>> On Tue, Oct 16, 2018 at 8:07 PM Bill Deegan <***@baddogconsulting.com>
>>>>> wrote:
>>>>>
>>>>>> You've still not replied with the compile command line.
>>>>>> Also what's your CPPPATH?
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 16, 2018 at 1:25 PM Hua Yanghao <***@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> it is the correct path and io.h is actually duplicated from
>>>>>>> firmware/include/io.h
>>>>>>>
>>>>>>> On Tue 16. Oct 2018 at 17:34, Bill Deegan <***@baddogconsulting.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Is `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' the
>>>>>>>> correct path to io.h?
>>>>>>>> Are you using duplicate=0, or not specifying in you SConscript()?
>>>>>>>> Are you using chdir somewhere in your SCons logic?
>>>>>>>>
>>>>>>>> Also, please paste the compile line for the compile which should
>>>>>>>> find io.h when it's passing?
>>>>>>>>
>>>>>>>> On Tue, Oct 16, 2018 at 11:14 AM Hua Yanghao <***@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> no it is static file.
>>>>>>>>>
>>>>>>>>> On Tue 16. Oct 2018 at 17:08, Bill Deegan <
>>>>>>>>> ***@baddogconsulting.com> wrote:
>>>>>>>>>
>>>>>>>>>> Is io.h a generated file?
>>>>>>>>>> Paste the compile line for the compile which should find io.h
>>>>>>>>>> when it's passing?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <***@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Bill,
>>>>>>>>>>> Yes io.h is on my CPPPATH. And I am using variant_dir="build" for
>>>>>>>>>>> SConscript files. So normally all used header files will end up
>>>>>>>>>>> in the
>>>>>>>>>>> build folder too. But occasionally scons seems missed it. I am
>>>>>>>>>>> struggling to reproduce it ...
>>>>>>>>>>>
>>>>>>>>>>> BR, Yanghao
>>>>>>>>>>> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <
>>>>>>>>>>> ***@baddogconsulting.com> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> > Yes. Headers are scanned recursively.
>>>>>>>>>>> > Implicit cache should only be enable by command line flag or
>>>>>>>>>>> SetOption()
>>>>>>>>>>> >
>>>>>>>>>>> > Where is io.h located? is it in your CPPPATH?
>>>>>>>>>>> >
>>>>>>>>>>> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <
>>>>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> By the way, is scons scanner scans C file headers
>>>>>>>>>>> recursively? Thanks.
>>>>>>>>>>> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <
>>>>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > scons: ***
>>>>>>>>>>> [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>>>>>>>>>>> >> > Implicit dependency
>>>>>>>>>>> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h'
>>>>>>>>>>> not found,
>>>>>>>>>>> >> > needed by target
>>>>>>>>>>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > I recently run into this odd problem, and it is very
>>>>>>>>>>> difficult to
>>>>>>>>>>> >> > reproduce. I did not explicitly enable the "implicit_cache"
>>>>>>>>>>> option
>>>>>>>>>>> >> > anywhere in my code. If I simply remove the build folder
>>>>>>>>>>> and then
>>>>>>>>>>> >> > re-build everything works as normal. the problem happens
>>>>>>>>>>> when there is
>>>>>>>>>>> >> > a old build, and then I pulled in some new code where this
>>>>>>>>>>> "test.c"
>>>>>>>>>>> >> > has included an additional header io.h and scons seems not
>>>>>>>>>>> re-scanning
>>>>>>>>>>> >> > the file by default.
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > I am using scons 3.0.1, is the implict_cache by default
>>>>>>>>>>> enabled there
>>>>>>>>>>> >> > and I have to disable it manually?
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > Thanks,
>>>>>>>>>>> >> > Yanghao Hua
>>>>>>>>>>> >> _______________________________________________
>>>>>>>>>>> >> Scons-users mailing list
>>>>>>>>>>> >> Scons-***@scons.org
>>>>>>>>>>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>> >
>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>> > Scons-users mailing list
>>>>>>>>>>> > Scons-***@scons.org
>>>>>>>>>>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Scons-users mailing list
>>>>>>>>>>> Scons-***@scons.org
>>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Scons-users mailing list
>>>>>>>>>> Scons-***@scons.org
>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Scons-users mailing list
>>>>>>>>> Scons-***@scons.org
>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Scons-users mailing list
>>>>>>>> Scons-***@scons.org
>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Scons-users mailing list
>>>>>>> Scons-***@scons.org
>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-***@scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-***@scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-***@scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>>

[Hua Yanghao]

Replied to the wrong threads .... re-attach it here.

Any thoughts? This seems really like when you move around some header
files scons is using some cached knowledge from last built which
caused the incremental built to fail.
Not sure if the trace file is useful enough already, I could try to
create a minimal suite of files that actually reproduce this issue too
if needed.

On Wed, Oct 17, 2018 at 10:37 PM Hua Yanghao <***@gmail.com> wrote:

> However, if on commit Y you do a clean and re-build, everything passes.
> Seems some cached state is in play here?
>
> On Wed, Oct 17, 2018 at 10:35 PM Hua Yanghao <***@gmail.com> wrote:
>
>> It looks like this time even though I reproduced the issue it is not
>> really sticky and always passes on a second run.
>> I have re-run with the trace: https://pastebin.com/2ziqM4ri
>>
>> The part that is important is there is one file, e.g. included <io.h>,
>> and in one version io.h is in folder A/io.h. And then there is a
>> restructure of file and io.h moved to folder B/io.h.
>> Folder A is in search path at commit X, build pass. Folder B is in search
>> path at commit Y, build pass too.
>>
>> However if you first build on commit X (pass) and then switch to commit Y
>> and build again, it fails like above.
>>
>> @Bill Deegan <***@baddogconsulting.com> please help to take a look the
>> trace file and let me know if more experiment I can do. At least now I can
>> reproduce it reliably on-demand.
>>
>> On Wed, Oct 17, 2018 at 10:06 PM Hua Yanghao <***@gmail.com>
>> wrote:
>>
>>> I finally reproduced this issue, however this
>>> --taskmastertrace=trace.log the compilation passes instead of failing.
>>> Thoughts?
>>>
>>> ***@huyangha-mobl:~/git/usw-abc $ ./run configs/pangu.py
>>> Running : ./tools/scons -Q config=configs/pangu.py
>>> INFO: Processing target usw ... Done.
>>> INFO: usw_config completed in 0.19 seconds.
>>> __CONFIG build/configs/pangu/usw/config/config.h
>>> ____SHCC build/configs/pangu/usw/firmware/arch/weak.os
>>> ______AR build/configs/pangu/usw/firmware/arch/libdefault.o
>>> __RANLIB build/configs/pangu/usw/firmware/arch/libdefault.o
>>> ____SHCC build/configs/pangu/usw/firmware/arch/pangu/lib.os
>>> ____SHCC build/configs/pangu/usw/firmware/arch/pangu/main.os
>>> scons: *** [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>>> Implicit dependency
>>> `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' not found,
>>> needed by target `build/configs/pangu/usw/firmware/arch/pangu/test.os'.
>>> ***@huyangha-mobl:~/git/usw-abc $ ./run configs/pangu.py
>>> --taskmastertrace=trace.log
>>> Running : ./tools/scons -Q config=configs/pangu.py
>>> --taskmastertrace=trace.log
>>> INFO: Processing target usw ... Done.
>>> INFO: usw_config completed in 0.21 seconds.
>>> __CONFIG build/configs/pangu/usw/config/config.h
>>> ____SHCC build/configs/pangu/usw/firmware/arch/pangu/test.os
>>> ____SHCC build/configs/pangu/usw/firmware/boards/weak.os
>>> ______AR build/configs/pangu/usw/firmware/boards/libdefault.o
>>> __RANLIB build/configs/pangu/usw/firmware/boards/libdefault.o
>>> ____SHCC build/configs/pangu/usw/firmware/boards/pangu/board.os
>>> ____SHCC build/configs/pangu/usw/firmware/common/cpu.os
>>> ____SHCC build/configs/pangu/usw/firmware/common/weak.os
>>> ____SHCC build/configs/pangu/usw/firmware/common/log.os
>>> ______AR build/configs/pangu/usw/firmware/common/libdefault.o
>>> __RANLIB build/configs/pangu/usw/firmware/common/libdefault.o
>>> ____SHCC build/configs/pangu/usw/firmware/common/main.os
>>> ____SHCC build/configs/pangu/usw/firmware/drivers/pcie/dwc_ep.os
>>> ______AR build/configs/pangu/usw/firmware/drivers/pcie/libdefault.o
>>> __RANLIB build/configs/pangu/usw/firmware/drivers/pcie/libdefault.o
>>> ____SHCC build/configs/pangu/usw/firmware/lib/cmd/cmd.os
>>> ____SHCC build/configs/pangu/usw/firmware/lib/cmd/test.os
>>> ____SHCC build/configs/pangu/usw/firmware/lib/fio/cmd.os
>>> ____SHCC build/configs/pangu/usw/firmware/lib/fio/usw_device.os
>>> ____SHCC build/configs/pangu/usw/firmware/lib/fio/linux64_device.os
>>> ______AR build/configs/pangu/usw/firmware/lib/fio/libdefault.o
>>> __RANLIB build/configs/pangu/usw/firmware/lib/fio/libdefault.o
>>> ____SHCC
>>> build/configs/pangu/usw/firmware/lib/simple_console/simple_console.os
>>> ______AR build/configs/pangu/usw/firmware/lib/simple_console/libdefault.o
>>> __RANLIB build/configs/pangu/usw/firmware/lib/simple_console/libdefault.o
>>> ____SHCC build/configs/pangu/usw/firmware/lib/simple_pipe/connect.os
>>> ____SHCC build/configs/pangu/usw/firmware/lib/simple_pipe/pipe.os
>>> ______AR build/configs/pangu/usw/firmware/lib/simple_pipe/libdefault.o
>>> __RANLIB build/configs/pangu/usw/firmware/lib/simple_pipe/libdefault.o
>>> ____SHCC build/configs/pangu/usw/firmware/test/console/hello.os
>>> ____SHCC build/configs/pangu/usw/firmware/test/console/test.os
>>> ____SHCC build/configs/pangu/usw/firmware/test/example/test.os
>>> ____SHLD build/configs/pangu/usw/libusw.so
>>> _USWHASH build/configs/pangu/usw/libusw.so
>>> _USWHASH build/configs/pangu/usw/libusw.so --> Changed
>>> ***@huyangha-mobl:~/git/usw-abc $
>>>
>>> On Tue, Oct 16, 2018 at 11:10 PM Hua Yanghao <***@gmail.com>
>>> wrote:
>>>
>>>> Config.h does not include any other headers. And the problem is it is
>>>> not easily reproducible. However once it happens it is sticky. I will try
>>>> harder tomorrow and get back to you. Thanks.
>>>>
>>>> On Tue 16. Oct 2018 at 23:06, Bill Deegan <***@baddogconsulting.com>
>>>> wrote:
>>>>
>>>>> Try running with
>>>>>
>>>>> --taskmastertrace=trace.log
>>>>>
>>>>> You'll get a pretty verbose log there, and search for io.h it should
>>>>> show more information about what's happening.
>>>>>
>>>>> Is io.h included via "-include config.h" ?
>>>>>
>>>>> -Bill
>>>>>
>>>>> On Tue, Oct 16, 2018 at 5:01 PM Hua Yanghao <***@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Bill,
>>>>>> Sorry I missed that one.
>>>>>>
>>>>>> The full command line when hit the failure:
>>>>>> gcc -o build/configs/pangu/usw/firmware/arch/pangu/test.os -c -g
>>>>>> -Wall -Werror -include config.h -Wno-error=main -Wno-main
>>>>>> -Wno-format-security -Wno-format -std=gnu99 -D_USW_FLAGS_TEST_0
>>>>>> -D_USW_FLAGS_TEST_1 -D_USW_FLAGS_TEST_2 -fPIC
>>>>>> -Ibuild/configs/pangu/usw/config
>>>>>> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/arch/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/common/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/test/example/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/test/console/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/boards/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
>>>>>> -Ibuild/configs/pangu/usw/config
>>>>>> -Ibuild/configs/pangu/usw/firmware/arch/pangu/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/arch/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/common/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/lib/cmd/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_pipe/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/lib/fio/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/lib/simple_console/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/test/example/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/test/console/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/boards/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/boards/pangu/include
>>>>>> -Ibuild/configs/pangu/usw/firmware/drivers/pcie/include
>>>>>> build/configs/pangu/usw/firmware/arch/pangu/test.c
>>>>>>
>>>>>> And my CPPPATH seems also matching the command line:
>>>>>> ['/home/hua/git/usw/build/configs/pangu/usw/config',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/config',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/pangu/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/arch/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/common/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/cmd/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_pipe/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/fio/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/lib/simple_console/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/example/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/test/console/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/boards/pangu/include',
>>>>>> '/home/hua/git/usw/build/configs/pangu/usw/firmware/drivers/pcie/include']
>>>>>>
>>>>>> Note the firmware/include is in both command line and CPPPATH, that's
>>>>>> where my io.h is located.
>>>>>>
>>>>>> Best Regards,
>>>>>> Yanghao
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 16, 2018 at 8:07 PM Bill Deegan <
>>>>>> ***@baddogconsulting.com> wrote:
>>>>>>
>>>>>>> You've still not replied with the compile command line.
>>>>>>> Also what's your CPPPATH?
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 16, 2018 at 1:25 PM Hua Yanghao <***@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> it is the correct path and io.h is actually duplicated from
>>>>>>>> firmware/include/io.h
>>>>>>>>
>>>>>>>> On Tue 16. Oct 2018 at 17:34, Bill Deegan <
>>>>>>>> ***@baddogconsulting.com> wrote:
>>>>>>>>
>>>>>>>>> Is `build/configs/pangu/usw/firmware/arch/pangu/include/io.h' the
>>>>>>>>> correct path to io.h?
>>>>>>>>> Are you using duplicate=0, or not specifying in you SConscript()?
>>>>>>>>> Are you using chdir somewhere in your SCons logic?
>>>>>>>>>
>>>>>>>>> Also, please paste the compile line for the compile which should
>>>>>>>>> find io.h when it's passing?
>>>>>>>>>
>>>>>>>>> On Tue, Oct 16, 2018 at 11:14 AM Hua Yanghao <***@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> no it is static file.
>>>>>>>>>>
>>>>>>>>>> On Tue 16. Oct 2018 at 17:08, Bill Deegan <
>>>>>>>>>> ***@baddogconsulting.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Is io.h a generated file?
>>>>>>>>>>> Paste the compile line for the compile which should find io.h
>>>>>>>>>>> when it's passing?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Oct 16, 2018 at 8:54 AM Hua Yanghao <
>>>>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Bill,
>>>>>>>>>>>> Yes io.h is on my CPPPATH. And I am using variant_dir="build"
>>>>>>>>>>>> for
>>>>>>>>>>>> SConscript files. So normally all used header files will end up
>>>>>>>>>>>> in the
>>>>>>>>>>>> build folder too. But occasionally scons seems missed it. I am
>>>>>>>>>>>> struggling to reproduce it ...
>>>>>>>>>>>>
>>>>>>>>>>>> BR, Yanghao
>>>>>>>>>>>> On Tue, Oct 16, 2018 at 2:51 PM Bill Deegan <
>>>>>>>>>>>> ***@baddogconsulting.com> wrote:
>>>>>>>>>>>> >
>>>>>>>>>>>> > Yes. Headers are scanned recursively.
>>>>>>>>>>>> > Implicit cache should only be enable by command line flag or
>>>>>>>>>>>> SetOption()
>>>>>>>>>>>> >
>>>>>>>>>>>> > Where is io.h located? is it in your CPPPATH?
>>>>>>>>>>>> >
>>>>>>>>>>>> > On Tue, Oct 16, 2018 at 6:43 AM Hua Yanghao <
>>>>>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> By the way, is scons scanner scans C file headers
>>>>>>>>>>>> recursively? Thanks.
>>>>>>>>>>>> >> On Tue, Oct 16, 2018 at 12:40 PM Hua Yanghao <
>>>>>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>>>>> >> >
>>>>>>>>>>>> >> > scons: ***
>>>>>>>>>>>> [build/configs/pangu/usw/firmware/arch/pangu/test.os]
>>>>>>>>>>>> >> > Implicit dependency
>>>>>>>>>>>> >> > `build/configs/pangu/usw/firmware/arch/pangu/include/io.h'
>>>>>>>>>>>> not found,
>>>>>>>>>>>> >> > needed by target
>>>>>>>>>>>> `build/configs/pangu/usw/firmware/arch/pangu/test.os'
>>>>>>>>>>>> >> >
>>>>>>>>>>>> >> > I recently run into this odd problem, and it is very
>>>>>>>>>>>> difficult to
>>>>>>>>>>>> >> > reproduce. I did not explicitly enable the
>>>>>>>>>>>> "implicit_cache" option
>>>>>>>>>>>> >> > anywhere in my code. If I simply remove the build folder
>>>>>>>>>>>> and then
>>>>>>>>>>>> >> > re-build everything works as normal. the problem happens
>>>>>>>>>>>> when there is
>>>>>>>>>>>> >> > a old build, and then I pulled in some new code where this
>>>>>>>>>>>> "test.c"
>>>>>>>>>>>> >> > has included an additional header io.h and scons seems not
>>>>>>>>>>>> re-scanning
>>>>>>>>>>>> >> > the file by default.
>>>>>>>>>>>> >> >
>>>>>>>>>>>> >> > I am using scons 3.0.1, is the implict_cache by default
>>>>>>>>>>>> enabled there
>>>>>>>>>>>> >> > and I have to disable it manually?
>>>>>>>>>>>> >> >
>>>>>>>>>>>> >> > Thanks,
>>>>>>>>>>>> >> > Yanghao Hua
>>>>>>>>>>>> >> _______________________________________________
>>>>>>>>>>>> >> Scons-users mailing list
>>>>>>>>>>>> >> Scons-***@scons.org
>>>>>>>>>>>> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>>> >
>>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>>> > Scons-users mailing list
>>>>>>>>>>>> > Scons-***@scons.org
>>>>>>>>>>>> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Scons-users mailing list
>>>>>>>>>>>> Scons-***@scons.org
>>>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Scons-users mailing list
>>>>>>>>>>> Scons-***@scons.org
>>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Scons-users mailing list
>>>>>>>>>> Scons-***@scons.org
>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Scons-users mailing list
>>>>>>>>> Scons-***@scons.org
>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Scons-users mailing list
>>>>>>>> Scons-***@scons.org
>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Scons-users mailing list
>>>>>>> Scons-***@scons.org
>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-***@scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-***@scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>>

[Mats Wichmann]

On 10/24/2018 09:05 AM, Hua Yanghao wrote:
> Replied to the wrong threads .... re-attach it here.
>
> Any thoughts? This seems really like when you move around some header
> files scons is using some cached knowledge from last built which
> caused the incremental built to fail.
> Not sure if the trace file is useful enough already, I could try to
> create a minimal suite of files that actually reproduce this issue too
> if needed.

if there's a small reproducer that's the basis for a test case, so
that's always welcome....

[Hua Yanghao]

Hi Mats and all, finally I extract out the essence of my build system
and come up with a simple setup that can reproduce the same issue
easily:
https://github.com/yanghao/scons_incremental_build_fail

Please follow the README.md file there to reproduce the issue (100%
success rate on my side, scons 3.0.1).

Best Regards,
Yanghao
On Wed, Oct 24, 2018 at 6:57 PM Mats Wichmann <***@wichmann.us> wrote:
>
> On 10/24/2018 09:05 AM, Hua Yanghao wrote:
> > Replied to the wrong threads .... re-attach it here.
> >
> > Any thoughts? This seems really like when you move around some header
> > files scons is using some cached knowledge from last built which
> > caused the incremental built to fail.
> > Not sure if the trace file is useful enough already, I could try to
> > create a minimal suite of files that actually reproduce this issue too
> > if needed.
>
> if there's a small reproducer that's the basis for a test case, so
> that's always welcome....
>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users

[Mats Wichmann]

On 10/24/2018 02:29 PM, Hua Yanghao wrote:
> Hi Mats and all, finally I extract out the essence of my build system
> and come up with a simple setup that can reproduce the same issue
> easily:
> https://github.com/yanghao/scons_incremental_build_fail
>
> Please follow the README.md file there to reproduce the issue (100%
> success rate on my side, scons 3.0.1).
>
> Best Regards,
> Yanghao


Hmmm.

$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o build/a/test.o -c -Ibuild/a/include -Ibuild/b/include build/a/test.c
gcc -o build/b/test.o -c -Ibuild/a/include -Ibuild/b/include build/b/test.c
gcc -o build/hello build/a/test.o build/b/test.o
scons: done building targets.

[Hua Yanghao]

need two passdid u read readme.md

On Wed 24. Oct 2018 at 22:49, Mats Wichmann <***@wichmann.us> wrote:

> On 10/24/2018 02:29 PM, Hua Yanghao wrote:
> > Hi Mats and all, finally I extract out the essence of my build system
> > and come up with a simple setup that can reproduce the same issue
> > easily:
> > https://github.com/yanghao/scons_incremental_build_fail
> >
> > Please follow the README.md file there to reproduce the issue (100%
> > success rate on my side, scons 3.0.1).
> >
> > Best Regards,
> > Yanghao
>
>
> Hmmm.
>
> $ scons
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> gcc -o build/a/test.o -c -Ibuild/a/include -Ibuild/b/include build/a/test.c
> gcc -o build/b/test.o -c -Ibuild/a/include -Ibuild/b/include build/b/test.c
> gcc -o build/hello build/a/test.o build/b/test.o
> scons: done building targets.
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Mats Wichmann]

On 10/24/2018 04:46 PM, Hua Yanghao wrote:
> need two pass，did u read readme.md？

I missed a character when doing so... the ^

sorting through what this means, probably leave it to the experts.

[Mats Wichmann]

On 10/24/2018 02:29 PM, Hua Yanghao wrote:
> Hi Mats and all, finally I extract out the essence of my build system
> and come up with a simple setup that can reproduce the same issue
> easily:
> https://github.com/yanghao/scons_incremental_build_fail
>
> Please follow the README.md file there to reproduce the issue (100%
> success rate on my side, scons 3.0.1).


So it seems what you have is a "priming" build has deposited a copy of a
header in a variant tree. When the original header is removed, scons
gets confused - I assume it doesn't just start from "what it looks like
now" in your build/a but tries to check if build/a in any way needs
resyncing with what it is shadowing. And it doesn't have the
information to do that - build/a/include/test.h exists but
a/include/test.h does not.

does that accurately describe the scenario in your original problem, or
is it just an artifact of trying to build the reproducer?

[Hua Yanghao]

Hi Mats,
This is exactly what happened in my build system, where people move
header files around and then do a incremental compilation and it
failed.
Shouldn't scons always starts by checking if all the mirroring of
files in the build folder is actually up-to-date to the source
folders?
Refactoring and moving header files around is a very common operation
during project development, and the fact that the second pass builds
OK tells somehow scons was actually able to get this right, just not
on the first shot.

Best Regards,
Yanghao
On Thu, Oct 25, 2018 at 1:43 AM Mats Wichmann <***@wichmann.us> wrote:
>
> On 10/24/2018 02:29 PM, Hua Yanghao wrote:
> > Hi Mats and all, finally I extract out the essence of my build system
> > and come up with a simple setup that can reproduce the same issue
> > easily:
> > https://github.com/yanghao/scons_incremental_build_fail
> >
> > Please follow the README.md file there to reproduce the issue (100%
> > success rate on my side, scons 3.0.1).
>
>
> So it seems what you have is a "priming" build has deposited a copy of a
> header in a variant tree. When the original header is removed, scons
> gets confused - I assume it doesn't just start from "what it looks like
> now" in your build/a but tries to check if build/a in any way needs
> resyncing with what it is shadowing. And it doesn't have the
> information to do that - build/a/include/test.h exists but
> a/include/test.h does not.
>
> does that accurately describe the scenario in your original problem, or
> is it just an artifact of trying to build the reproducer?
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users

[Mats Wichmann]

On 10/25/2018 02:17 AM, Hua Yanghao wrote:
> Hi Mats,
> This is exactly what happened in my build system, where people move
> header files around and then do a incremental compilation and it
> failed.
> Shouldn't scons always starts by checking if all the mirroring of
> files in the build folder is actually up-to-date to the source
> folders?
> Refactoring and moving header files around is a very common operation
> during project development, and the fact that the second pass builds
> OK tells somehow scons was actually able to get this right, just not
> on the first shot.

If you want to see what scons "remembers", you can do this in your test
directory:

sconsign .sconsign.dblite

When I do that I see build/a/test.o has depends on its sources in
build/a, and I assume the error message means that scons concludes those
are not "real" files since they're under the variant dir.

Flipping your variant_dir calls to non-copying (add duplicate=0 to the
SConscript call), the test works for me, presumably because now there is
no dangling "reference" to a test.h that no longer exists. Just trying
to piece it together. With all respect to the core developers, I have
found the logic behind both forms of variant_dir (copying and
non-copying) to be a bit dodgy, I can't get either one to work quite as
my mental model would have them behave. Perhaps that's just faulty
mental models...


The interesting part here is for the case that's going to fail, we have:

=== build/a:
...
test.o: 745af4c9af338033022943cbc558f5e4 1540423561 1376
build/a/test.c: 4b4a4cc225f4757288dc5abbbc7cb14b 1540475790 109
build/a/include/test.h: b972e789a649e1bc6875ff6f40531f7e
1540475790 14

Without changing anything else, I change SConstruct to use non-copying
mode and rerun scons and it works, and the sconsign file now contains:

=== build/a:
...
test.o: 745af4c9af338033022943cbc558f5e4 1540480755 1376
a/test.c: 29f8028f861e5483353fd5d15dee8adb 1540480544 108
b/include/test.h: b972e789a649e1bc6875ff6f40531f7e 1540480544 14

so now the dependencies point to the "real" sources, not the
shadowed-by-copying ones....

Hmmm.

[Bill Deegan]

Yes. It should work as is with SCons.
Not sure exactly why it's not but looking into it.

It looks like using duplicate=0 should remove this issue for the time being.
Is that something you're able to do with your build?

=Bill

On Thu, Oct 25, 2018 at 8:29 AM Mats Wichmann <***@wichmann.us> wrote:

> On 10/25/2018 02:17 AM, Hua Yanghao wrote:
> > Hi Mats,
> > This is exactly what happened in my build system, where people move
> > header files around and then do a incremental compilation and it
> > failed.
> > Shouldn't scons always starts by checking if all the mirroring of
> > files in the build folder is actually up-to-date to the source
> > folders?
> > Refactoring and moving header files around is a very common operation
> > during project development, and the fact that the second pass builds
> > OK tells somehow scons was actually able to get this right, just not
> > on the first shot.
>
> If you want to see what scons "remembers", you can do this in your test
> directory:
>
> sconsign .sconsign.dblite
>
> When I do that I see build/a/test.o has depends on its sources in
> build/a, and I assume the error message means that scons concludes those
> are not "real" files since they're under the variant dir.
>
> Flipping your variant_dir calls to non-copying (add duplicate=0 to the
> SConscript call), the test works for me, presumably because now there is
> no dangling "reference" to a test.h that no longer exists. Just trying
> to piece it together. With all respect to the core developers, I have
> found the logic behind both forms of variant_dir (copying and
> non-copying) to be a bit dodgy, I can't get either one to work quite as
> my mental model would have them behave. Perhaps that's just faulty
> mental models...
>
>
> The interesting part here is for the case that's going to fail, we have:
>
> === build/a:
> ...
> test.o: 745af4c9af338033022943cbc558f5e4 1540423561 1376
> build/a/test.c: 4b4a4cc225f4757288dc5abbbc7cb14b 1540475790 109
> build/a/include/test.h: b972e789a649e1bc6875ff6f40531f7e
> 1540475790 14
>
> Without changing anything else, I change SConstruct to use non-copying
> mode and rerun scons and it works, and the sconsign file now contains:
>
> === build/a:
> ...
> test.o: 745af4c9af338033022943cbc558f5e4 1540480755 1376
> a/test.c: 29f8028f861e5483353fd5d15dee8adb 1540480544 108
> b/include/test.h: b972e789a649e1bc6875ff6f40531f7e 1540480544 14
>
> so now the dependencies point to the "real" sources, not the
> shadowed-by-copying ones....
>
> Hmmm.
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Hua Yanghao]

Hi Bill,
Unfortunately not for my real build out of box.
I think I should be able to modify my build system to avoid using
duplicate, but that's actually one of the feature I love most ... e.g.
for every single build I have a exact snapshot of only those source
files (include .h files) that actually being used, and I could simply
package the build folder for a self-contained build. As all of the
build shares the same sources this way it is very clear to understand
what actually went into the build.

It is definitely not showstopper, as you just need to build it again
when it failed or simply do a clean before re-build. It is just a bit
annoying knowing that incremental build could fail when you move
around header files and having duplicate enabled.

I will also try to look into the source code as Mats did but not sure
if I can make much sense out of it quickly ...

Best Regards,
Yanghao
On Thu, Oct 25, 2018 at 6:44 PM Bill Deegan <***@baddogconsulting.com> wrote:
>
> Yes. It should work as is with SCons.
> Not sure exactly why it's not but looking into it.
>
> It looks like using duplicate=0 should remove this issue for the time being.
> Is that something you're able to do with your build?
>
> =Bill
>
> On Thu, Oct 25, 2018 at 8:29 AM Mats Wichmann <***@wichmann.us> wrote:
>>
>> On 10/25/2018 02:17 AM, Hua Yanghao wrote:
>> > Hi Mats,
>> > This is exactly what happened in my build system, where people move
>> > header files around and then do a incremental compilation and it
>> > failed.
>> > Shouldn't scons always starts by checking if all the mirroring of
>> > files in the build folder is actually up-to-date to the source
>> > folders?
>> > Refactoring and moving header files around is a very common operation
>> > during project development, and the fact that the second pass builds
>> > OK tells somehow scons was actually able to get this right, just not
>> > on the first shot.
>>
>> If you want to see what scons "remembers", you can do this in your test
>> directory:
>>
>> sconsign .sconsign.dblite
>>
>> When I do that I see build/a/test.o has depends on its sources in
>> build/a, and I assume the error message means that scons concludes those
>> are not "real" files since they're under the variant dir.
>>
>> Flipping your variant_dir calls to non-copying (add duplicate=0 to the
>> SConscript call), the test works for me, presumably because now there is
>> no dangling "reference" to a test.h that no longer exists. Just trying
>> to piece it together. With all respect to the core developers, I have
>> found the logic behind both forms of variant_dir (copying and
>> non-copying) to be a bit dodgy, I can't get either one to work quite as
>> my mental model would have them behave. Perhaps that's just faulty
>> mental models...
>>
>>
>> The interesting part here is for the case that's going to fail, we have:
>>
>> === build/a:
>> ...
>> test.o: 745af4c9af338033022943cbc558f5e4 1540423561 1376
>> build/a/test.c: 4b4a4cc225f4757288dc5abbbc7cb14b 1540475790 109
>> build/a/include/test.h: b972e789a649e1bc6875ff6f40531f7e
>> 1540475790 14
>>
>> Without changing anything else, I change SConstruct to use non-copying
>> mode and rerun scons and it works, and the sconsign file now contains:
>>
>> === build/a:
>> ...
>> test.o: 745af4c9af338033022943cbc558f5e4 1540480755 1376
>> a/test.c: 29f8028f861e5483353fd5d15dee8adb 1540480544 108
>> b/include/test.h: b972e789a649e1bc6875ff6f40531f7e 1540480544 14
>>
>> so now the dependencies point to the "real" sources, not the
>> shadowed-by-copying ones....
>>
>> Hmmm.
>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users

[Jason Kenny]

I have had various issue with duplicate=1. I myself default use duplicate=0 myself. In both cases I believe the source directory and the variant directory are added to the path. If i understand right you have the case in which you need the builder to run in the variant dir and having duplicate=1 means you should have copies or link to the source file in the variant which will make the tool work.

are you having a case in which your tool cannot accept a $SOURCE value that would point to the file in some place that is not the current directory?

Jason
________________________________
From: Scons-users <scons-users-***@scons.org> on behalf of Hua Yanghao <***@gmail.com>
Sent: Thursday, October 25, 2018 1:27 PM
To: SCons users mailing list
Subject: Re: [Scons-users] Scons Implicity Dependency not found issue

Hi Bill,
Unfortunately not for my real build out of box.
I think I should be able to modify my build system to avoid using
duplicate, but that's actually one of the feature I love most ... e.g.
for every single build I have a exact snapshot of only those source
files (include .h files) that actually being used, and I could simply
package the build folder for a self-contained build. As all of the
build shares the same sources this way it is very clear to understand
what actually went into the build.

It is definitely not showstopper, as you just need to build it again
when it failed or simply do a clean before re-build. It is just a bit
annoying knowing that incremental build could fail when you move
around header files and having duplicate enabled.

I will also try to look into the source code as Mats did but not sure
if I can make much sense out of it quickly ...

Best Regards,
Yanghao
On Thu, Oct 25, 2018 at 6:44 PM Bill Deegan <***@baddogconsulting.com> wrote:
>
> Yes. It should work as is with SCons.
> Not sure exactly why it's not but looking into it.
>
> It looks like using duplicate=0 should remove this issue for the time being.
> Is that something you're able to do with your build?
>
> =Bill
>
> On Thu, Oct 25, 2018 at 8:29 AM Mats Wichmann <***@wichmann.us> wrote:
>>
>> On 10/25/2018 02:17 AM, Hua Yanghao wrote:
>> > Hi Mats,
>> > This is exactly what happened in my build system, where people move
>> > header files around and then do a incremental compilation and it
>> > failed.
>> > Shouldn't scons always starts by checking if all the mirroring of
>> > files in the build folder is actually up-to-date to the source
>> > folders?
>> > Refactoring and moving header files around is a very common operation
>> > during project development, and the fact that the second pass builds
>> > OK tells somehow scons was actually able to get this right, just not
>> > on the first shot.
>>
>> If you want to see what scons "remembers", you can do this in your test
>> directory:
>>
>> sconsign .sconsign.dblite
>>
>> When I do that I see build/a/test.o has depends on its sources in
>> build/a, and I assume the error message means that scons concludes those
>> are not "real" files since they're under the variant dir.
>>
>> Flipping your variant_dir calls to non-copying (add duplicate=0 to the
>> SConscript call), the test works for me, presumably because now there is
>> no dangling "reference" to a test.h that no longer exists. Just trying
>> to piece it together. With all respect to the core developers, I have
>> found the logic behind both forms of variant_dir (copying and
>> non-copying) to be a bit dodgy, I can't get either one to work quite as
>> my mental model would have them behave. Perhaps that's just faulty
>> mental models...
>>
>>
>> The interesting part here is for the case that's going to fail, we have:
>>
>> === build/a:
>> ...
>> test.o: 745af4c9af338033022943cbc558f5e4 1540423561 1376
>> build/a/test.c: 4b4a4cc225f4757288dc5abbbc7cb14b 1540475790 109
>> build/a/include/test.h: b972e789a649e1bc6875ff6f40531f7e
>> 1540475790 14
>>
>> Without changing anything else, I change SConstruct to use non-copying
>> mode and rerun scons and it works, and the sconsign file now contains:
>>
>> === build/a:
>> ...
>> test.o: 745af4c9af338033022943cbc558f5e4 1540480755 1376
>> a/test.c: 29f8028f861e5483353fd5d15dee8adb 1540480544 108
>> b/include/test.h: b972e789a649e1bc6875ff6f40531f7e 1540480544 14
>>
>> so now the dependencies point to the "real" sources, not the
>> shadowed-by-copying ones....
>>
>> Hmmm.
>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7C96025d888bb841a3025708d63aa78a08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760888575981043&amp;sdata=%2B6GJG3cTWwgyrK%2BWsvpurWG4OiItHiffkOlHoY7eoxc%3D&amp;reserved=0
>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7C96025d888bb841a3025708d63aa78a08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760888575981043&amp;sdata=%2B6GJG3cTWwgyrK%2BWsvpurWG4OiItHiffkOlHoY7eoxc%3D&amp;reserved=0

[Hua Yanghao]

Hi Jason,
I am pretty sure (though not yet tried) I can convert and use
duplicate=0, this is independent of the stripping of the variant_dir
issue we discussed in the other thread.
The only reason I am using duplicate=1 is: 1. it is the default (means
scons recommended?) 2. I really like to have a clear copy of those
files that has been used.

I do not have any use case where the tool cannot accept a $SOURCE
value that points to the original file path.

Best Regards,
Yanghao
On Thu, Oct 25, 2018 at 8:37 PM Jason Kenny <***@live.com> wrote:
>
> I have had various issue with duplicate=1. I myself default use duplicate=0 myself. In both cases I believe the source directory and the variant directory are added to the path. If i understand right you have the case in which you need the builder to run in the variant dir and having duplicate=1 means you should have copies or link to the source file in the variant which will make the tool work.
>
> are you having a case in which your tool cannot accept a $SOURCE value that would point to the file in some place that is not the current directory?
>
> Jason
> ________________________________
> From: Scons-users <scons-users-***@scons.org> on behalf of Hua Yanghao <***@gmail.com>
> Sent: Thursday, October 25, 2018 1:27 PM
> To: SCons users mailing list
> Subject: Re: [Scons-users] Scons Implicity Dependency not found issue
>
> Hi Bill,
> Unfortunately not for my real build out of box.
> I think I should be able to modify my build system to avoid using
> duplicate, but that's actually one of the feature I love most ... e.g.
> for every single build I have a exact snapshot of only those source
> files (include .h files) that actually being used, and I could simply
> package the build folder for a self-contained build. As all of the
> build shares the same sources this way it is very clear to understand
> what actually went into the build.
>
> It is definitely not showstopper, as you just need to build it again
> when it failed or simply do a clean before re-build. It is just a bit
> annoying knowing that incremental build could fail when you move
> around header files and having duplicate enabled.
>
> I will also try to look into the source code as Mats did but not sure
> if I can make much sense out of it quickly ...
>
> Best Regards,
> Yanghao
> On Thu, Oct 25, 2018 at 6:44 PM Bill Deegan <***@baddogconsulting.com> wrote:
> >
> > Yes. It should work as is with SCons.
> > Not sure exactly why it's not but looking into it.
> >
> > It looks like using duplicate=0 should remove this issue for the time being.
> > Is that something you're able to do with your build?
> >
> > =Bill
> >
> > On Thu, Oct 25, 2018 at 8:29 AM Mats Wichmann <***@wichmann.us> wrote:
> >>
> >> On 10/25/2018 02:17 AM, Hua Yanghao wrote:
> >> > Hi Mats,
> >> > This is exactly what happened in my build system, where people move
> >> > header files around and then do a incremental compilation and it
> >> > failed.
> >> > Shouldn't scons always starts by checking if all the mirroring of
> >> > files in the build folder is actually up-to-date to the source
> >> > folders?
> >> > Refactoring and moving header files around is a very common operation
> >> > during project development, and the fact that the second pass builds
> >> > OK tells somehow scons was actually able to get this right, just not
> >> > on the first shot.
> >>
> >> If you want to see what scons "remembers", you can do this in your test
> >> directory:
> >>
> >> sconsign .sconsign.dblite
> >>
> >> When I do that I see build/a/test.o has depends on its sources in
> >> build/a, and I assume the error message means that scons concludes those
> >> are not "real" files since they're under the variant dir.
> >>
> >> Flipping your variant_dir calls to non-copying (add duplicate=0 to the
> >> SConscript call), the test works for me, presumably because now there is
> >> no dangling "reference" to a test.h that no longer exists. Just trying
> >> to piece it together. With all respect to the core developers, I have
> >> found the logic behind both forms of variant_dir (copying and
> >> non-copying) to be a bit dodgy, I can't get either one to work quite as
> >> my mental model would have them behave. Perhaps that's just faulty
> >> mental models...
> >>
> >>
> >> The interesting part here is for the case that's going to fail, we have:
> >>
> >> === build/a:
> >> ...
> >> test.o: 745af4c9af338033022943cbc558f5e4 1540423561 1376
> >> build/a/test.c: 4b4a4cc225f4757288dc5abbbc7cb14b 1540475790 109
> >> build/a/include/test.h: b972e789a649e1bc6875ff6f40531f7e
> >> 1540475790 14
> >>
> >> Without changing anything else, I change SConstruct to use non-copying
> >> mode and rerun scons and it works, and the sconsign file now contains:
> >>
> >> === build/a:
> >> ...
> >> test.o: 745af4c9af338033022943cbc558f5e4 1540480755 1376
> >> a/test.c: 29f8028f861e5483353fd5d15dee8adb 1540480544 108
> >> b/include/test.h: b972e789a649e1bc6875ff6f40531f7e 1540480544 14
> >>
> >> so now the dependencies point to the "real" sources, not the
> >> shadowed-by-copying ones....
> >>
> >> Hmmm.
> >>
> >>
> >> _______________________________________________
> >> Scons-users mailing list
> >> Scons-***@scons.org
> >> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7C96025d888bb841a3025708d63aa78a08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760888575981043&amp;sdata=%2B6GJG3cTWwgyrK%2BWsvpurWG4OiItHiffkOlHoY7eoxc%3D&amp;reserved=0
> >
> > _______________________________________________
> > Scons-users mailing list
> > Scons-***@scons.org
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7C96025d888bb841a3025708d63aa78a08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760888575981043&amp;sdata=%2B6GJG3cTWwgyrK%2BWsvpurWG4OiItHiffkOlHoY7eoxc%3D&amp;reserved=0
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7C96025d888bb841a3025708d63aa78a08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760888575981043&amp;sdata=%2B6GJG3cTWwgyrK%2BWsvpurWG4OiItHiffkOlHoY7eoxc%3D&amp;reserved=0

[Jason Kenny]

Hi,

I would recommend myself that you use duplicate=0 then. The point for duplicate=1 as default is that there are some tools that don't deal with files input output location and to help avoid possible issues if you have a large build and you might have modified a file while the build was going on ( given you tell SCons to make copies instead of hardlinks... ie this is the --duplicate option). There are a few issues with this however:

1) windows will make copies as SCons does not understand symlink or hard links on this platform with out some extension added to it
2) takes extra times as one has to create items
3) when it is making copies I have had issues I cannot explain yet ( ie not looked in to enough) where scons does not update the files in the variantdir correctly making bad builds. ( I think that is what you are seeing)

For large build the time save with duplicate=0 is a big deal, as well as the disk savings given the hard-soft-copy options is not working correctly

Bill -- just a guess but I think the issue when copy is being used is that SCons nodes understand the variant and srcnode exists, but has no check, or depends logic to say variant version depends on the srcnode version so there are cases in which a depends on a variant node does mean that the srcnode "copy" update is not seen. So for example the scanner does gets a file and tests that it exists, but since the header does not have any builder the logic to understand that the it should update based on the value of srcnode() version is skipped.

-Jason
________________________________
From: Hua Yanghao <***@gmail.com>
Sent: Thursday, October 25, 2018 1:51 PM
To: ***@live.com
Cc: SCons users mailing list
Subject: Re: [Scons-users] Scons Implicity Dependency not found issue

Hi Jason,
I am pretty sure (though not yet tried) I can convert and use
duplicate=0, this is independent of the stripping of the variant_dir
issue we discussed in the other thread.
The only reason I am using duplicate=1 is: 1. it is the default (means
scons recommended?) 2. I really like to have a clear copy of those
files that has been used.

I do not have any use case where the tool cannot accept a $SOURCE
value that points to the original file path.

Best Regards,
Yanghao
On Thu, Oct 25, 2018 at 8:37 PM Jason Kenny <***@live.com> wrote:
>
> I have had various issue with duplicate=1. I myself default use duplicate=0 myself. In both cases I believe the source directory and the variant directory are added to the path. If i understand right you have the case in which you need the builder to run in the variant dir and having duplicate=1 means you should have copies or link to the source file in the variant which will make the tool work.
>
> are you having a case in which your tool cannot accept a $SOURCE value that would point to the file in some place that is not the current directory?
>
> Jason
> ________________________________
> From: Scons-users <scons-users-***@scons.org> on behalf of Hua Yanghao <***@gmail.com>
> Sent: Thursday, October 25, 2018 1:27 PM
> To: SCons users mailing list
> Subject: Re: [Scons-users] Scons Implicity Dependency not found issue
>
> Hi Bill,
> Unfortunately not for my real build out of box.
> I think I should be able to modify my build system to avoid using
> duplicate, but that's actually one of the feature I love most ... e.g.
> for every single build I have a exact snapshot of only those source
> files (include .h files) that actually being used, and I could simply
> package the build folder for a self-contained build. As all of the
> build shares the same sources this way it is very clear to understand
> what actually went into the build.
>
> It is definitely not showstopper, as you just need to build it again
> when it failed or simply do a clean before re-build. It is just a bit
> annoying knowing that incremental build could fail when you move
> around header files and having duplicate enabled.
>
> I will also try to look into the source code as Mats did but not sure
> if I can make much sense out of it quickly ...
>
> Best Regards,
> Yanghao
> On Thu, Oct 25, 2018 at 6:44 PM Bill Deegan <***@baddogconsulting.com> wrote:
> >
> > Yes. It should work as is with SCons.
> > Not sure exactly why it's not but looking into it.
> >
> > It looks like using duplicate=0 should remove this issue for the time being.
> > Is that something you're able to do with your build?
> >
> > =Bill
> >
> > On Thu, Oct 25, 2018 at 8:29 AM Mats Wichmann <***@wichmann.us> wrote:
> >>
> >> On 10/25/2018 02:17 AM, Hua Yanghao wrote:
> >> > Hi Mats,
> >> > This is exactly what happened in my build system, where people move
> >> > header files around and then do a incremental compilation and it
> >> > failed.
> >> > Shouldn't scons always starts by checking if all the mirroring of
> >> > files in the build folder is actually up-to-date to the source
> >> > folders?
> >> > Refactoring and moving header files around is a very common operation
> >> > during project development, and the fact that the second pass builds
> >> > OK tells somehow scons was actually able to get this right, just not
> >> > on the first shot.
> >>
> >> If you want to see what scons "remembers", you can do this in your test
> >> directory:
> >>
> >> sconsign .sconsign.dblite
> >>
> >> When I do that I see build/a/test.o has depends on its sources in
> >> build/a, and I assume the error message means that scons concludes those
> >> are not "real" files since they're under the variant dir.
> >>
> >> Flipping your variant_dir calls to non-copying (add duplicate=0 to the
> >> SConscript call), the test works for me, presumably because now there is
> >> no dangling "reference" to a test.h that no longer exists. Just trying
> >> to piece it together. With all respect to the core developers, I have
> >> found the logic behind both forms of variant_dir (copying and
> >> non-copying) to be a bit dodgy, I can't get either one to work quite as
> >> my mental model would have them behave. Perhaps that's just faulty
> >> mental models...
> >>
> >>
> >> The interesting part here is for the case that's going to fail, we have:
> >>
> >> === build/a:
> >> ...
> >> test.o: 745af4c9af338033022943cbc558f5e4 1540423561 1376
> >> build/a/test.c: 4b4a4cc225f4757288dc5abbbc7cb14b 1540475790 109
> >> build/a/include/test.h: b972e789a649e1bc6875ff6f40531f7e
> >> 1540475790 14
> >>
> >> Without changing anything else, I change SConstruct to use non-copying
> >> mode and rerun scons and it works, and the sconsign file now contains:
> >>
> >> === build/a:
> >> ...
> >> test.o: 745af4c9af338033022943cbc558f5e4 1540480755 1376
> >> a/test.c: 29f8028f861e5483353fd5d15dee8adb 1540480544 108
> >> b/include/test.h: b972e789a649e1bc6875ff6f40531f7e 1540480544 14
> >>
> >> so now the dependencies point to the "real" sources, not the
> >> shadowed-by-copying ones....
> >>
> >> Hmmm.
> >>
> >>
> >> _______________________________________________
> >> Scons-users mailing list
> >> Scons-***@scons.org
> >> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7Cde06ffb3a830484d389608d63aaae420%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760902970322438&amp;sdata=nuF8C5CrX6Qdg6IGm12Bo6uEjirDPzLCBtrO8idvGJw%3D&amp;reserved=0
> >
> > _______________________________________________
> > Scons-users mailing list
> > Scons-***@scons.org
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7Cde06ffb3a830484d389608d63aaae420%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760902970322438&amp;sdata=nuF8C5CrX6Qdg6IGm12Bo6uEjirDPzLCBtrO8idvGJw%3D&amp;reserved=0
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7Cde06ffb3a830484d389608d63aaae420%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760902970322438&amp;sdata=nuF8C5CrX6Qdg6IGm12Bo6uEjirDPzLCBtrO8idvGJw%3D&amp;reserved=0

[Bill Deegan]

Jason,

I believe the scanner is seeing the file, and then the duplicate logic is
removing it, so when the taskmaster goes to walk it, it fails.
I haven't had a chance to verify this hypothesis.
Likely the common usage is not to explicitly list the variant dir
equivalent of the source in the CPPPATH?
-Bill

On Thu, Oct 25, 2018 at 1:09 PM Jason Kenny <***@live.com> wrote:

> Hi,
>
> I would recommend myself that you use duplicate=0 then. The point for
> duplicate=1 as default is that there are some tools that don't deal with
> files input output location and to help avoid possible issues if you have a
> large build and you might have modified a file while the build was going on
> ( given you tell SCons to make copies instead of hardlinks... ie this is
> the --duplicate option). There are a few issues with this however:
>
> 1) windows will make copies as SCons does not understand symlink or hard
> links on this platform with out some extension added to it
> 2) takes extra times as one has to create items
> 3) when it is making copies I have had issues I cannot explain yet ( ie
> not looked in to enough) where scons does not update the files in the
> variantdir correctly making bad builds. ( I think that is what you are
> seeing)
>
> For large build the time save with duplicate=0 is a big deal, as well as
> the disk savings given the hard-soft-copy options is not working correctly
>
> Bill -- just a guess but I think the issue when copy is being used is that
> SCons nodes understand the variant and srcnode exists, but has no check, or
> depends logic to say variant version depends on the srcnode version so
> there are cases in which a depends on a variant node does mean that the
> srcnode "copy" update is not seen. So for example the scanner does gets a
> file and tests that it exists, but since the header does not have any
> builder the logic to understand that the it should update based on the
> value of srcnode() version is skipped.
>
> -Jason
> ------------------------------
> *From:* Hua Yanghao <***@gmail.com>
> *Sent:* Thursday, October 25, 2018 1:51 PM
> *To:* ***@live.com
> *Cc:* SCons users mailing list
> *Subject:* Re: [Scons-users] Scons Implicity Dependency not found issue
>
> Hi Jason,
> I am pretty sure (though not yet tried) I can convert and use
> duplicate=0, this is independent of the stripping of the variant_dir
> issue we discussed in the other thread.
> The only reason I am using duplicate=1 is: 1. it is the default (means
> scons recommended?) 2. I really like to have a clear copy of those
> files that has been used.
>
> I do not have any use case where the tool cannot accept a $SOURCE
> value that points to the original file path.
>
> Best Regards,
> Yanghao
> On Thu, Oct 25, 2018 at 8:37 PM Jason Kenny <***@live.com> wrote:
> >
> > I have had various issue with duplicate=1. I myself default use
> duplicate=0 myself. In both cases I believe the source directory and the
> variant directory are added to the path. If i understand right you have the
> case in which you need the builder to run in the variant dir and having
> duplicate=1 means you should have copies or link to the source file in the
> variant which will make the tool work.
> >
> > are you having a case in which your tool cannot accept a $SOURCE value
> that would point to the file in some place that is not the current
> directory?
> >
> > Jason
> > ________________________________
> > From: Scons-users <scons-users-***@scons.org> on behalf of Hua
> Yanghao <***@gmail.com>
> > Sent: Thursday, October 25, 2018 1:27 PM
> > To: SCons users mailing list
> > Subject: Re: [Scons-users] Scons Implicity Dependency not found issue
> >
> > Hi Bill,
> > Unfortunately not for my real build out of box.
> > I think I should be able to modify my build system to avoid using
> > duplicate, but that's actually one of the feature I love most ... e.g.
> > for every single build I have a exact snapshot of only those source
> > files (include .h files) that actually being used, and I could simply
> > package the build folder for a self-contained build. As all of the
> > build shares the same sources this way it is very clear to understand
> > what actually went into the build.
> >
> > It is definitely not showstopper, as you just need to build it again
> > when it failed or simply do a clean before re-build. It is just a bit
> > annoying knowing that incremental build could fail when you move
> > around header files and having duplicate enabled.
> >
> > I will also try to look into the source code as Mats did but not sure
> > if I can make much sense out of it quickly ...
> >
> > Best Regards,
> > Yanghao
> > On Thu, Oct 25, 2018 at 6:44 PM Bill Deegan <***@baddogconsulting.com>
> wrote:
> > >
> > > Yes. It should work as is with SCons.
> > > Not sure exactly why it's not but looking into it.
> > >
> > > It looks like using duplicate=0 should remove this issue for the time
> being.
> > > Is that something you're able to do with your build?
> > >
> > > =Bill
> > >
> > > On Thu, Oct 25, 2018 at 8:29 AM Mats Wichmann <***@wichmann.us>
> wrote:
> > >>
> > >> On 10/25/2018 02:17 AM, Hua Yanghao wrote:
> > >> > Hi Mats,
> > >> > This is exactly what happened in my build system, where people move
> > >> > header files around and then do a incremental compilation and it
> > >> > failed.
> > >> > Shouldn't scons always starts by checking if all the mirroring of
> > >> > files in the build folder is actually up-to-date to the source
> > >> > folders?
> > >> > Refactoring and moving header files around is a very common
> operation
> > >> > during project development, and the fact that the second pass builds
> > >> > OK tells somehow scons was actually able to get this right, just not
> > >> > on the first shot.
> > >>
> > >> If you want to see what scons "remembers", you can do this in your
> test
> > >> directory:
> > >>
> > >> sconsign .sconsign.dblite
> > >>
> > >> When I do that I see build/a/test.o has depends on its sources in
> > >> build/a, and I assume the error message means that scons concludes
> those
> > >> are not "real" files since they're under the variant dir.
> > >>
> > >> Flipping your variant_dir calls to non-copying (add duplicate=0 to the
> > >> SConscript call), the test works for me, presumably because now there
> is
> > >> no dangling "reference" to a test.h that no longer exists. Just
> trying
> > >> to piece it together. With all respect to the core developers, I have
> > >> found the logic behind both forms of variant_dir (copying and
> > >> non-copying) to be a bit dodgy, I can't get either one to work quite
> as
> > >> my mental model would have them behave. Perhaps that's just faulty
> > >> mental models...
> > >>
> > >>
> > >> The interesting part here is for the case that's going to fail, we
> have:
> > >>
> > >> === build/a:
> > >> ...
> > >> test.o: 745af4c9af338033022943cbc558f5e4 1540423561 1376
> > >> build/a/test.c: 4b4a4cc225f4757288dc5abbbc7cb14b 1540475790
> 109
> > >> build/a/include/test.h: b972e789a649e1bc6875ff6f40531f7e
> > >> 1540475790 14
> > >>
> > >> Without changing anything else, I change SConstruct to use non-copying
> > >> mode and rerun scons and it works, and the sconsign file now contains:
> > >>
> > >> === build/a:
> > >> ...
> > >> test.o: 745af4c9af338033022943cbc558f5e4 1540480755 1376
> > >> a/test.c: 29f8028f861e5483353fd5d15dee8adb 1540480544 108
> > >> b/include/test.h: b972e789a649e1bc6875ff6f40531f7e 1540480544
> 14
> > >>
> > >> so now the dependencies point to the "real" sources, not the
> > >> shadowed-by-copying ones....
> > >>
> > >> Hmmm.
> > >>
> > >>
> > >> _______________________________________________
> > >> Scons-users mailing list
> > >> Scons-***@scons.org
> > >>
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7Cde06ffb3a830484d389608d63aaae420%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760902970322438&amp;sdata=nuF8C5CrX6Qdg6IGm12Bo6uEjirDPzLCBtrO8idvGJw%3D&amp;reserved=0
> > >
> > > _______________________________________________
> > > Scons-users mailing list
> > > Scons-***@scons.org
> > >
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7Cde06ffb3a830484d389608d63aaae420%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760902970322438&amp;sdata=nuF8C5CrX6Qdg6IGm12Bo6uEjirDPzLCBtrO8idvGJw%3D&amp;reserved=0
> > _______________________________________________
> > Scons-users mailing list
> > Scons-***@scons.org
> >
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7Cde06ffb3a830484d389608d63aaae420%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760902970322438&amp;sdata=nuF8C5CrX6Qdg6IGm12Bo6uEjirDPzLCBtrO8idvGJw%3D&amp;reserved=0
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Hua Yanghao]

On Fri, Oct 26, 2018 at 1:56 AM Bill Deegan <***@baddogconsulting.com> wrote:
>
> Jason,
>
> I believe the scanner is seeing the file, and then the duplicate logic is removing it, so when the taskmaster goes to walk it, it fails.
> I haven't had a chance to verify this hypothesis.
> Likely the common usage is not to explicitly list the variant dir equivalent of the source in the CPPPATH?

If the build/a/include is not on CPPPATH, no header file will be
copied over to variant_dir. I think I had experimented a lot to find
this trick ;-)

[Hua Yanghao]

On Thu, Oct 25, 2018 at 10:08 PM Jason Kenny <***@live.com> wrote:
>
> Hi,
>
> I would recommend myself that you use duplicate=0 then. The point for duplicate=1 as default is that there are some tools that don't deal with files input output location and to help avoid possible issues if you have a large build and you might have modified a file while the build was going on ( given you tell SCons to make copies instead of hardlinks... ie this is the --duplicate option). There are a few issues with this however:
>
> 1) windows will make copies as SCons does not understand symlink or hard links on this platform with out some extension added to it
> 2) takes extra times as one has to create items
> 3) when it is making copies I have had issues I cannot explain yet ( ie not looked in to enough) where scons does not update the files in the variantdir correctly making bad builds. ( I think that is what you are seeing)
>
> For large build the time save with duplicate=0 is a big deal, as well as the disk savings given the hard-soft-copy options is not working correctly
>
> Bill -- just a guess but I think the issue when copy is being used is that SCons nodes understand the variant and srcnode exists, but has no check, or depends logic to say variant version depends on the srcnode version so there are cases in which a depends on a variant node does mean that the srcnode "copy" update is not seen. So for example the scanner does gets a file and tests that it exists, but since the header does not have any builder the logic to understand that the it should update based on the value of srcnode() version is skipped.
>
> -Jason

Thanks Jason. I am seriously considering doing so now ...

[Hua Yanghao]

On Fri, Oct 26, 2018 at 9:45 AM Hua Yanghao <***@gmail.com> wrote:
>
> On Thu, Oct 25, 2018 at 10:08 PM Jason Kenny <***@live.com> wrote:
> >
> > Hi,
> >
> > I would recommend myself that you use duplicate=0 then. The point for duplicate=1 as default is that there are some tools that don't deal with files input output location and to help avoid possible issues if you have a large build and you might have modified a file while the build was going on ( given you tell SCons to make copies instead of hardlinks... ie this is the --duplicate option). There are a few issues with this however:
> >
> > 1) windows will make copies as SCons does not understand symlink or hard links on this platform with out some extension added to it
> > 2) takes extra times as one has to create items
> > 3) when it is making copies I have had issues I cannot explain yet ( ie not looked in to enough) where scons does not update the files in the variantdir correctly making bad builds. ( I think that is what you are seeing)
> >
> > For large build the time save with duplicate=0 is a big deal, as well as the disk savings given the hard-soft-copy options is not working correctly
> >
> > Bill -- just a guess but I think the issue when copy is being used is that SCons nodes understand the variant and srcnode exists, but has no check, or depends logic to say variant version depends on the srcnode version so there are cases in which a depends on a variant node does mean that the srcnode "copy" update is not seen. So for example the scanner does gets a file and tests that it exists, but since the header does not have any builder the logic to understand that the it should update based on the value of srcnode() version is skipped.
> >
> > -Jason
>
> Thanks Jason. I am seriously considering doing so now ...

In my build system, I made a clear decision that all compiled files
goes to the variant_dir, such that the source folders are intact. This
enabled a uniform way to specifying external dependencies where either
a scons scanner is missing. Now If I use duplicate=0, then I need two
different system to specify this kind of dependency, one for the files
that is in the original source folders, and one for the files that is
created on the fly in the variant_dir ... this breaks user APIs ...
but I do see the build speed up quite a bit.

So finally I come up with a new user-visible API that in SConscript
for users: usw_board_path(fn): return
os.path.join("#"+env["USW_BUILD_PATH"], env["USW_BUILD_FOLDER"], fn),
I can see sometimes, especially with variant_dir, scons tries to be
really smart (maybe a bit too much) that it tries to translate every
single path it sees if without the leading #.

I think I will settle with this one, looks like we really should use
duplicate with great caution.

Thanks Jason for sharing the experience of duplicate=1.

BR, Yanghao

[Hua Yanghao]

Now I am surprised and confused that my above usw_board_path(fn) is
completely redundant ... as I forgot to update one of the SConscript
file and realize everything still works as expected and no broken
dependencies, and with --tree=all I see that between variant_dir &
original_dir scons just automatically picked up the right dependencies
... I am having difficulties to understand this, for example, what if
I have a file in the original source and on-the-fly created a
different file of the same name in the variant_dir path ... which one
scons will be picking up ... or will there be a error saying they are
the same file?!
On Fri, Oct 26, 2018 at 2:59 PM Hua Yanghao <***@gmail.com> wrote:
>
> On Fri, Oct 26, 2018 at 9:45 AM Hua Yanghao <***@gmail.com> wrote:
> >
> > On Thu, Oct 25, 2018 at 10:08 PM Jason Kenny <***@live.com> wrote:
> > >
> > > Hi,
> > >
> > > I would recommend myself that you use duplicate=0 then. The point for duplicate=1 as default is that there are some tools that don't deal with files input output location and to help avoid possible issues if you have a large build and you might have modified a file while the build was going on ( given you tell SCons to make copies instead of hardlinks... ie this is the --duplicate option). There are a few issues with this however:
> > >
> > > 1) windows will make copies as SCons does not understand symlink or hard links on this platform with out some extension added to it
> > > 2) takes extra times as one has to create items
> > > 3) when it is making copies I have had issues I cannot explain yet ( ie not looked in to enough) where scons does not update the files in the variantdir correctly making bad builds. ( I think that is what you are seeing)
> > >
> > > For large build the time save with duplicate=0 is a big deal, as well as the disk savings given the hard-soft-copy options is not working correctly
> > >
> > > Bill -- just a guess but I think the issue when copy is being used is that SCons nodes understand the variant and srcnode exists, but has no check, or depends logic to say variant version depends on the srcnode version so there are cases in which a depends on a variant node does mean that the srcnode "copy" update is not seen. So for example the scanner does gets a file and tests that it exists, but since the header does not have any builder the logic to understand that the it should update based on the value of srcnode() version is skipped.
> > >
> > > -Jason
> >
> > Thanks Jason. I am seriously considering doing so now ...
>
> In my build system, I made a clear decision that all compiled files
> goes to the variant_dir, such that the source folders are intact. This
> enabled a uniform way to specifying external dependencies where either
> a scons scanner is missing. Now If I use duplicate=0, then I need two
> different system to specify this kind of dependency, one for the files
> that is in the original source folders, and one for the files that is
> created on the fly in the variant_dir ... this breaks user APIs ...
> but I do see the build speed up quite a bit.
>
> So finally I come up with a new user-visible API that in SConscript
> for users: usw_board_path(fn): return
> os.path.join("#"+env["USW_BUILD_PATH"], env["USW_BUILD_FOLDER"], fn),
> I can see sometimes, especially with variant_dir, scons tries to be
> really smart (maybe a bit too much) that it tries to translate every
> single path it sees if without the leading #.
>
> I think I will settle with this one, looks like we really should use
> duplicate with great caution.
>
> Thanks Jason for sharing the experience of duplicate=1.
>
> BR, Yanghao

[Bill Deegan]

Wouldn't this work?

def usw_board_path(fn):
return "#"/$USW_BUILD_PATH/$USE_BUILD_FOLDER/%s"%fn

On Fri, Oct 26, 2018 at 5:59 AM Hua Yanghao <***@gmail.com> wrote:

> On Fri, Oct 26, 2018 at 9:45 AM Hua Yanghao <***@gmail.com> wrote:
> >
> > On Thu, Oct 25, 2018 at 10:08 PM Jason Kenny <***@live.com> wrote:
> > >
> > > Hi,
> > >
> > > I would recommend myself that you use duplicate=0 then. The point for
> duplicate=1 as default is that there are some tools that don't deal with
> files input output location and to help avoid possible issues if you have a
> large build and you might have modified a file while the build was going on
> ( given you tell SCons to make copies instead of hardlinks... ie this is
> the --duplicate option). There are a few issues with this however:
> > >
> > > 1) windows will make copies as SCons does not understand symlink or
> hard links on this platform with out some extension added to it
> > > 2) takes extra times as one has to create items
> > > 3) when it is making copies I have had issues I cannot explain yet (
> ie not looked in to enough) where scons does not update the files in the
> variantdir correctly making bad builds. ( I think that is what you are
> seeing)
> > >
> > > For large build the time save with duplicate=0 is a big deal, as well
> as the disk savings given the hard-soft-copy options is not working
> correctly
> > >
> > > Bill -- just a guess but I think the issue when copy is being used is
> that SCons nodes understand the variant and srcnode exists, but has no
> check, or depends logic to say variant version depends on the srcnode
> version so there are cases in which a depends on a variant node does mean
> that the srcnode "copy" update is not seen. So for example the scanner does
> gets a file and tests that it exists, but since the header does not have
> any builder the logic to understand that the it should update based on the
> value of srcnode() version is skipped.
> > >
> > > -Jason
> >
> > Thanks Jason. I am seriously considering doing so now ...
>
> In my build system, I made a clear decision that all compiled files
> goes to the variant_dir, such that the source folders are intact. This
> enabled a uniform way to specifying external dependencies where either
> a scons scanner is missing. Now If I use duplicate=0, then I need two
> different system to specify this kind of dependency, one for the files
> that is in the original source folders, and one for the files that is
> created on the fly in the variant_dir ... this breaks user APIs ...
> but I do see the build speed up quite a bit.
>
> So finally I come up with a new user-visible API that in SConscript
> for users: usw_board_path(fn): return
> os.path.join("#"+env["USW_BUILD_PATH"], env["USW_BUILD_FOLDER"], fn),
> I can see sometimes, especially with variant_dir, scons tries to be
> really smart (maybe a bit too much) that it tries to translate every
> single path it sees if without the leading #.
>
> I think I will settle with this one, looks like we really should use
> duplicate with great caution.
>
> Thanks Jason for sharing the experience of duplicate=1.
>
> BR, Yanghao
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Jason Kenny]

I think I solved this problem in Parts already. Each "component" gets builds and has a set of dependencies on other components. These dependency allow the passing of various values such as CPPPATH etc so only the ideal paths and location are known when the component builds. This prevent the issues of picking up headers from random components that may cause a circular depends or unexpected depends on other component.

But to try to answer you question... if you use duplicate=0 and you copy a header file in to the variant directory.. this should take over as the one seen first. It also should be a mirror of the srcnode version. ie contents of node and node.srcnode() should be the same.

Jason
________________________________
From: Scons-users <scons-users-***@scons.org> on behalf of Bill Deegan <***@baddogconsulting.com>
Sent: Friday, October 26, 2018 10:18 AM
To: SCons users mailing list
Subject: Re: [Scons-users] Scons Implicity Dependency not found issue

Wouldn't this work?

def usw_board_path(fn):
return "#"/$USW_BUILD_PATH/$USE_BUILD_FOLDER/%s"%fn

On Fri, Oct 26, 2018 at 5:59 AM Hua Yanghao <***@gmail.com<mailto:***@gmail.com>> wrote:
On Fri, Oct 26, 2018 at 9:45 AM Hua Yanghao <***@gmail.com<mailto:***@gmail.com>> wrote:
>
> On Thu, Oct 25, 2018 at 10:08 PM Jason Kenny <***@live.com<mailto:***@live.com>> wrote:
> >
> > Hi,
> >
> > I would recommend myself that you use duplicate=0 then. The point for duplicate=1 as default is that there are some tools that don't deal with files input output location and to help avoid possible issues if you have a large build and you might have modified a file while the build was going on ( given you tell SCons to make copies instead of hardlinks... ie this is the --duplicate option). There are a few issues with this however:
> >
> > 1) windows will make copies as SCons does not understand symlink or hard links on this platform with out some extension added to it
> > 2) takes extra times as one has to create items
> > 3) when it is making copies I have had issues I cannot explain yet ( ie not looked in to enough) where scons does not update the files in the variantdir correctly making bad builds. ( I think that is what you are seeing)
> >
> > For large build the time save with duplicate=0 is a big deal, as well as the disk savings given the hard-soft-copy options is not working correctly
> >
> > Bill -- just a guess but I think the issue when copy is being used is that SCons nodes understand the variant and srcnode exists, but has no check, or depends logic to say variant version depends on the srcnode version so there are cases in which a depends on a variant node does mean that the srcnode "copy" update is not seen. So for example the scanner does gets a file and tests that it exists, but since the header does not have any builder the logic to understand that the it should update based on the value of srcnode() version is skipped.
> >
> > -Jason
>
> Thanks Jason. I am seriously considering doing so now ...

In my build system, I made a clear decision that all compiled files
goes to the variant_dir, such that the source folders are intact. This
enabled a uniform way to specifying external dependencies where either
a scons scanner is missing. Now If I use duplicate=0, then I need two
different system to specify this kind of dependency, one for the files
that is in the original source folders, and one for the files that is
created on the fly in the variant_dir ... this breaks user APIs ...
but I do see the build speed up quite a bit.

So finally I come up with a new user-visible API that in SConscript
for users: usw_board_path(fn): return
os.path.join("#"+env["USW_BUILD_PATH"], env["USW_BUILD_FOLDER"], fn),
I can see sometimes, especially with variant_dir, scons tries to be
really smart (maybe a bit too much) that it tries to translate every
single path it sees if without the leading #.

I think I will settle with this one, looks like we really should use
duplicate with great caution.

Thanks Jason for sharing the experience of duplicate=1.

BR, Yanghao

[Hua Yanghao]

On Fri, Oct 26, 2018 at 6:09 PM Jason Kenny <***@live.com> wrote:
>
> I think I solved this problem in Parts already. Each "component" gets builds and has a set of dependencies on other components. These dependency allow the passing of various values such as CPPPATH etc so only the ideal paths and location are known when the component builds. This prevent the issues of picking up headers from random components that may cause a circular depends or unexpected depends on other component.

This is a very good point and it is actually on my TODO list for more
than a year already ... In my case components can define a macro which
passed to top level and this way serves as a
inter-component-communication mechanism. For me the module
inter-dependency should not only be object-compilable, but also
linkable to avoid some silly header file declares functions the module
doesn't really implement.

> But to try to answer you question... if you use duplicate=0 and you copy a header file in to the variant directory.. this should take over as the one seen first. It also should be a mirror of the srcnode version. ie contents of node and node.srcnode() should be the same.

No that is not my intention. I never copy any files from my code, I
was only relying scons to duplicate header files. I do create
on-the-fly generated header files directly in the variant_dir. If I
create a target header file in variant_dir with the same path/name as
in the src dir, then whichever file scons choose it is wrong. I kind
of avoid this situation though though a checking script to make sure
no two header file are of the same name ...

[Hua Yanghao]

Isn't os.path.join() a bit more portable? though I don't and won't
care about windows.
I see no difference.
On Fri, Oct 26, 2018 at 5:18 PM Bill Deegan <***@baddogconsulting.com> wrote:
>
> Wouldn't this work?
>
> def usw_board_path(fn):
> return "#"/$USW_BUILD_PATH/$USE_BUILD_FOLDER/%s"%fn
>
> On Fri, Oct 26, 2018 at 5:59 AM Hua Yanghao <***@gmail.com> wrote:
>>
>> On Fri, Oct 26, 2018 at 9:45 AM Hua Yanghao <***@gmail.com> wrote:
>> >
>> > On Thu, Oct 25, 2018 at 10:08 PM Jason Kenny <***@live.com> wrote:
>> > >
>> > > Hi,
>> > >
>> > > I would recommend myself that you use duplicate=0 then. The point for duplicate=1 as default is that there are some tools that don't deal with files input output location and to help avoid possible issues if you have a large build and you might have modified a file while the build was going on ( given you tell SCons to make copies instead of hardlinks... ie this is the --duplicate option). There are a few issues with this however:
>> > >
>> > > 1) windows will make copies as SCons does not understand symlink or hard links on this platform with out some extension added to it
>> > > 2) takes extra times as one has to create items
>> > > 3) when it is making copies I have had issues I cannot explain yet ( ie not looked in to enough) where scons does not update the files in the variantdir correctly making bad builds. ( I think that is what you are seeing)
>> > >
>> > > For large build the time save with duplicate=0 is a big deal, as well as the disk savings given the hard-soft-copy options is not working correctly
>> > >
>> > > Bill -- just a guess but I think the issue when copy is being used is that SCons nodes understand the variant and srcnode exists, but has no check, or depends logic to say variant version depends on the srcnode version so there are cases in which a depends on a variant node does mean that the srcnode "copy" update is not seen. So for example the scanner does gets a file and tests that it exists, but since the header does not have any builder the logic to understand that the it should update based on the value of srcnode() version is skipped.
>> > >
>> > > -Jason
>> >
>> > Thanks Jason. I am seriously considering doing so now ...
>>
>> In my build system, I made a clear decision that all compiled files
>> goes to the variant_dir, such that the source folders are intact. This
>> enabled a uniform way to specifying external dependencies where either
>> a scons scanner is missing. Now If I use duplicate=0, then I need two
>> different system to specify this kind of dependency, one for the files
>> that is in the original source folders, and one for the files that is
>> created on the fly in the variant_dir ... this breaks user APIs ...
>> but I do see the build speed up quite a bit.
>>
>> So finally I come up with a new user-visible API that in SConscript
>> for users: usw_board_path(fn): return
>> os.path.join("#"+env["USW_BUILD_PATH"], env["USW_BUILD_FOLDER"], fn),
>> I can see sometimes, especially with variant_dir, scons tries to be
>> really smart (maybe a bit too much) that it tries to translate every
>> single path it sees if without the leading #.
>>
>> I think I will settle with this one, looks like we really should use
>> duplicate with great caution.
>>
>> Thanks Jason for sharing the experience of duplicate=1.
>>
>> BR, Yanghao
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users