Discussion:
[Scons-users] Randomly, Scons can not find the header
shijm
2017-11-20 08:04:38 UTC
Permalink
@Bill Deegan Thanks very much for your response


The command is :
"g++ -o <build path>/abc.os -I<path1> -I<path2> <build path>/abc.cpp "


In fact, the 'abc.h' and 'abc.cpp' are in the same dir, and the include way is '#include "abc.h"' using double quotation;
So, I think the compiler should just find the header file in the current dir, and the '-I' option is not used in this case, Is that right?


In addition, in your above message, what does the "proper dependencies" exactly means? Does my case above have the "proper dependencies"?


Thanks very much!
Send Scons-users mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
https://pairlist4.pair.net/mailman/listinfo/scons-users
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Scons-users digest..."
1. Re: Randomly, Scons can not find the header files(#include)
(Bill Deegan)
2. Re: Randomly, Scons can not find the header files(#include)
(Bill Deegan)
3. Re: problem with new Jar builder-wrapper in 3.0.1 (Bill Deegan)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Nov 2017 10:57:19 -0500
Subject: Re: [Scons-users] Randomly, Scons can not find the header
files(#include)
Content-Type: text/plain; charset="utf-8"
What's the command line when it fails?
Does it have the -I's?
A WAG would be that another file has the proper dependencies on the file
and thus it's getting copied to build dir, while the one(s) which fail do
not. Thus if the order of compilation changes it may not be copied in time..
-Bill
Hi,
I?m using Scons 2.3 to compile our projects, but *randomly**,* scans can
{ xxx.cpp:5:37: error: xxx.h: No such file or directory }
1. One SConstruct in the root dir, and lots of SConscript in different
sub dirs
2. env.SConscript(dirs='.',exports='env',variant_dir=env[
'BUILD_DIR'],duplicate=1)
3. SetOption('duplicate','hard-soft-copy')
4. In each sub SConscript we define env: Import('env?); env = env.Clone
()
5. Also, we are using CPPPATH to search the header files
When compiling, we always clone a clean code from remote repo, so there is
no cache or something else locally.
Then the problem is, sometimes the compilation is success, sometimes it's
failure, I try to figure out the root cause and found that the header file
was not copied to 'BUILD_DIR'(duplicate=1);
I don't know why this happened, seams there is some wrong when parsing
dependency tree or cp files? I don't know.
So, do you have some ideas or suggestions for me to fix/debug this issue?
Looking forward to your response! thanks very much!!!
Thanks.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171117/6afabdd4/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 17 Nov 2017 10:57:36 -0500
Subject: Re: [Scons-users] Randomly, Scons can not find the header
files(#include)
Content-Type: text/plain; charset="utf-8"
Also.. Try 3.0.1 and see if the problem goes away.
2.3 is quite old.
What's the command line when it fails?
Does it have the -I's?
A WAG would be that another file has the proper dependencies on the file
and thus it's getting copied to build dir, while the one(s) which fail do
not. Thus if the order of compilation changes it may not be copied in time..
-Bill
Hi,
I?m using Scons 2.3 to compile our projects, but *randomly**,* scans can
{ xxx.cpp:5:37: error: xxx.h: No such file or directory }
1. One SConstruct in the root dir, and lots of SConscript in
different sub dirs
2. env.SConscript(dirs='.',exports='env',variant_dir=env['
BUILD_DIR'],duplicate=1)
3. SetOption('duplicate','hard-soft-copy')
4. In each sub SConscript we define env: Import('env?); env =
env.Clone()
5. Also, we are using CPPPATH to search the header files
When compiling, we always clone a clean code from remote repo, so there
is no cache or something else locally.
Then the problem is, sometimes the compilation is success, sometimes it's
failure, I try to figure out the root cause and found that the header file
was not copied to 'BUILD_DIR'(duplicate=1);
I don't know why this happened, seams there is some wrong when parsing
dependency tree or cp files? I don't know.
So, do you have some ideas or suggestions for me to fix/debug this issue?
Looking forward to your response! thanks very much!!!
Thanks.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171117/5cfa4411/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 17 Nov 2017 11:03:41 -0500
Subject: Re: [Scons-users] problem with new Jar builder-wrapper in
3.0.1
Content-Type: text/plain; charset="utf-8"
Mats,
All return values from builders are NodeLists, (list of nodes)
source=simpleclient_classes+['MANIFEST.MF'])
I've also added a link to this thread in the pull request. Hopefully Daniel
Moody will respond here.
-Bill
Per the instructions still on the scons.org page, I'm emailing this here
prior to filing a ticket.
When I tried our build with 3.0.1., the CI builders for the java
versions tipped over.
15:34:53 File
"/home/jenkins-ci/workspace/iotivity-verify-linux_secured_
with_java/java/examples-java/simpleclient/SConscript",
15:34:53 example_jar = jdk_env.Jar(target='simpleclient.jar',
source=[simpleclient_classes, 'MANIFEST.MF'])
15:34:53 File
"/home/jenkins-ci/workspace/iotivity-verify-linux_secured_
with_java/scons-local/scons-local-3.0.1/SCons/Environment.py",
15:34:53 return self.method(*nargs, **kwargs)
15:34:53 File
"/home/jenkins-ci/workspace/iotivity-verify-linux_secured_
with_java/scons-local/scons-local-3.0.1/SCons/Tool/jar.py",
15:34:53 st = os.stat(path)
"""
A pseudo-Builder wrapper around the separate Jar sources{File,Dir}
Builders.
"""
simpleclient_classes = jdk_env.Java(target='classes',
source=['src/main/java'])
example_jar = jdk_env.Jar(target='simpleclient.jar',
source=[simpleclient_classes, 'MANIFEST.MF'])
(the second line is the one from the traceback)
so the return from the Java builder is passed to Jar as part of the
source list, but the new code does not appear to expect the type it is
passed as a result. It's not clear if our call to Jar is illegal, but
it worked fine through 3.0.0. It *looks* like the intent is not to do
it the way we do, since the preceding call to the Java builder seems
"Any .java files in the source list will be compiled to .class files by
calling the Java Builder. "
So it would be good to figure out if this is a new bug in jar.py, or if
the documentation should be explicit about disallowing the way we are
calling it, which at least to my reading it is not explicit about.
thanks,
-- mats
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171117/9d4073f4/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users
------------------------------
End of Scons-users Digest, Vol 71, Issue 22
*******************************************
Bill Deegan
2017-11-20 13:49:15 UTC
Permalink
Is abc.h a generated file? Or does it exist before SCons runs?
Have you tried running with scons 3.0.1?
2.3 is pretty old and many bugs have been fixed since that was released.

-Bill
Post by shijm
@Bill Deegan Thanks very much for your response
"g++ -o <build path>/abc.os -I<path1> -I<path2> <build path>/abc.cpp "
In fact, the 'abc.h' and 'abc.cpp' are in the same dir, and the include
way is '#include "abc.h"' using double quotation;
So, I think the compiler should just find the header file in the current
dir, and the '-I' option is not used in this case, Is that right?
In addition, in your above message, what does the "proper dependencies"
exactly means? Does my case above have the "proper dependencies"?
Thanks very much!
Send Scons-users mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
https://pairlist4.pair.net/mailman/listinfo/scons-users
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Scons-users digest..."
1. Re: Randomly, Scons can not find the header files(#include)
(Bill Deegan)
2. Re: Randomly, Scons can not find the header files(#include)
(Bill Deegan)
3. Re: problem with new Jar builder-wrapper in 3.0.1 (Bill Deegan)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Nov 2017 10:57:19 -0500
Subject: Re: [Scons-users] Randomly, Scons can not find the header
files(#include)
Content-Type: text/plain; charset="utf-8"
What's the command line when it fails?
Does it have the -I's?
A WAG would be that another file has the proper dependencies on the file
and thus it's getting copied to build dir, while the one(s) which fail do
not. Thus if the order of compilation changes it may not be copied in time..
-Bill
Hi,
I?m using Scons 2.3 to compile our projects, but *randomly**,* scans can
{ xxx.cpp:5:37: error: xxx.h: No such file or directory }
1. One SConstruct in the root dir, and lots of SConscript in different
sub dirs
2. env.SConscript(dirs='.',exports='env',variant_dir=env[
'BUILD_DIR'],duplicate=1)
3. SetOption('duplicate','hard-soft-copy')
4. In each sub SConscript we define env: Import('env?); env = env.Clone
()
5. Also, we are using CPPPATH to search the header files
When compiling, we always clone a clean code from remote repo, so there is
no cache or something else locally.
Then the problem is, sometimes the compilation is success, sometimes it's
failure, I try to figure out the root cause and found that the header file
was not copied to 'BUILD_DIR'(duplicate=1);
I don't know why this happened, seams there is some wrong when parsing
dependency tree or cp files? I don't know.
So, do you have some ideas or suggestions for me to fix/debug this issue?
Looking forward to your response! thanks very much!!!
Thanks.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171117/6afabdd4/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 17 Nov 2017 10:57:36 -0500
Subject: Re: [Scons-users] Randomly, Scons can not find the header
files(#include)
Content-Type: text/plain; charset="utf-8"
Also.. Try 3.0.1 and see if the problem goes away.
2.3 is quite old.
What's the command line when it fails?
Does it have the -I's?
A WAG would be that another file has the proper dependencies on the file
and thus it's getting copied to build dir, while the one(s) which fail do
not. Thus if the order of compilation changes it may not be copied in time..
-Bill
Hi,
I?m using Scons 2.3 to compile our projects, but *randomly**,* scans can
{ xxx.cpp:5:37: error: xxx.h: No such file or directory }
1. One SConstruct in the root dir, and lots of SConscript in
different sub dirs
2. env.SConscript(dirs='.',exports='env',variant_dir=env['
BUILD_DIR'],duplicate=1)
3. SetOption('duplicate','hard-soft-copy')
4. In each sub SConscript we define env: Import('env?); env =
env.Clone()
5. Also, we are using CPPPATH to search the header files
When compiling, we always clone a clean code from remote repo, so there
is no cache or something else locally.
Then the problem is, sometimes the compilation is success, sometimes it's
failure, I try to figure out the root cause and found that the header file
was not copied to 'BUILD_DIR'(duplicate=1);
I don't know why this happened, seams there is some wrong when parsing
dependency tree or cp files? I don't know.
So, do you have some ideas or suggestions for me to fix/debug this issue?
Looking forward to your response! thanks very much!!!
Thanks.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171117/5cfa4411/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 17 Nov 2017 11:03:41 -0500
Subject: Re: [Scons-users] problem with new Jar builder-wrapper in
3.0.1
Content-Type: text/plain; charset="utf-8"
Mats,
All return values from builders are NodeLists, (list of nodes)
source=simpleclient_classes+['MANIFEST.MF'])
I've also added a link to this thread in the pull request. Hopefully Daniel
Moody will respond here.
-Bill
Per the instructions still on the scons.org page, I'm emailing this here
prior to filing a ticket.
When I tried our build with 3.0.1., the CI builders for the java
versions tipped over.
15:34:53 File
"/home/jenkins-ci/workspace/iotivity-verify-linux_secured_
with_java/java/examples-java/simpleclient/SConscript",
15:34:53 example_jar = jdk_env.Jar(target='simpleclient.jar',
source=[simpleclient_classes, 'MANIFEST.MF'])
15:34:53 File
"/home/jenkins-ci/workspace/iotivity-verify-linux_secured_
with_java/scons-local/scons-local-3.0.1/SCons/Environment.py",
15:34:53 return self.method(*nargs, **kwargs)
15:34:53 File
"/home/jenkins-ci/workspace/iotivity-verify-linux_secured_
with_java/scons-local/scons-local-3.0.1/SCons/Tool/jar.py",
15:34:53 st = os.stat(path)
"""
A pseudo-Builder wrapper around the separate Jar sources{File,Dir}
Builders.
"""
simpleclient_classes = jdk_env.Java(target='classes',
source=['src/main/java'])
example_jar = jdk_env.Jar(target='simpleclient.jar',
source=[simpleclient_classes, 'MANIFEST.MF'])
(the second line is the one from the traceback)
so the return from the Java builder is passed to Jar as part of the
source list, but the new code does not appear to expect the type it is
passed as a result. It's not clear if our call to Jar is illegal, but
it worked fine through 3.0.0. It *looks* like the intent is not to do
it the way we do, since the preceding call to the Java builder seems
"Any .java files in the source list will be compiled to .class files by
calling the Java Builder. "
So it would be good to figure out if this is a new bug in jar.py, or if
the documentation should be explicit about disallowing the way we are
calling it, which at least to my reading it is not explicit about.
thanks,
-- mats
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171117/9d4073f4/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users
------------------------------
End of Scons-users Digest, Vol 71, Issue 22
*******************************************
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users
Loading...