[Scons-users] Using CheckFunc() and CheckLib() breaks dependencies and makes scons ignore file changes

Tue Feb 14 19:20:47 EST 2017

There are multiple issues in general:

  1.  Any build breaks inside Check* are not breaking the whole build (considering that it’s the lib required by the rest of the project that is failing to build inside that call).
  2.  All source file changes for libs build by Check* are ignored.
  3.  The build information for the lib is enclosed inside config.log and I guess it would be nice to propagate this information to standard scons output. Especially in case of a failure. Again, only for the libs required by the rest of the project.
  4.  The cleanup seems to be broken and everything built by Check* never gets removed, if you run scons with “-c”.
  5.  You’re right, that “foo” is removed from the LIBS – I haven’t noticed that initially.

Also, I’ve included the successful version as the original, because (in my opinion) it’s easier to break something than try to figure out how it’s broken. But I’ve mentioned, that one has to change foo.c, to see the other issues.

We’re cleaning up our build scripts and shouldn’t see this issue any more soon, but it seems like it might cause a lot of confusing and hard to find problems for other people, so I’m glad, that this was found and can be turned into a bug. What is the preferred way to do this, though, because scon’s web site only mentions that I should “follow the instructions the community provides to file a new bug”? I can follow the guidelines<http://scons.tigris.org/bug-submission.html#guidelines>, but want to make sure, that there isn’t anything more to it.

Thanks,
Pawel

From: Bill Deegan [mailto:bill at baddogconsulting.com]
Sent: Tuesday, February 14, 2017 14:57
To: Pawel Winogrodzki <pawelwi at microsoft.com>
Cc: SCons users mailing list <scons-users at scons.org>
Subject: Re: [Scons-users] Using CheckFunc() and CheckLib() breaks dependencies and makes scons ignore file changes

On Tue, Feb 14, 2017 at 1:00 PM, Pawel Winogrodzki <pawelwi at microsoft.com<mailto:pawelwi at microsoft.com>> wrote:
In our case the library itself should be linked against most of the other ones anyway. That’s not really the main issue I wanted to point out, though.

The problem is, that scons ignores any failures when building lib “foo” from the Check* and also drops building any targets, which had a dependency on this lib, while at the same time indicating to the developer, that the build was successful. We (and I’m assuming many other projects) rely on scons’ build status in our automated builds and checks before allowing new code to be merged and in this case we can end up with a code change breaking the build without realizing it. At least not as soon as it should be.

So in this case the issue is not so much that the library failed to build which caused the Check* method to fail, but that since the library is used in the actual build, and it failed, an error should have propagated..  And curiously the library is removed from the LIBS? And/or SCons is not executing the program link at all..

O.k. that looks like a real bug.

Though your test case doesn't replicate the failure, only the success.
I had to stick some gibberish into foo.c to see the failure.
After a short look, it's likely an issue in the Taskmaster.
From taskmaster trace log:
Taskmaster: Looking for a node to evaluate
Taskmaster:     Considering node <up_to_date 0   'bar.c'> and its children:
Taskmaster:        already handled (executed)
Taskmaster:     Considering node <executed   0   'bar.o'> and its children:
Taskmaster:        already handled (executed)
Taskmaster:     Considering node <no_state   0   'foo'> and its children:
Taskmaster:        <no_state   0   'foo/SConscript'>
Taskmaster:        <up_to_date 0   'foo/foo.c'>
Taskmaster:        <up_to_date 0   'foo/foo.h'>
Taskmaster:        <failed     0   'foo/foo.o'>
Taskmaster:        <failed     0   'foo/libfooLib.a'>
Taskmaster: ****** <failed     0   'foo'>

It may take some time to resolve.

If using environments containing libs built within the project for the purpose of running Check* methods is bad practice, then I guess at least a warning from scons in such case might be a good idea, but still using Check* incorrectly should not mask failing builds. At least in this simple example I’ve sent it seems to me scons should indicate, that it couldn’t build “bar”.

Perhaps it should be better documented that anything in the Environment() used to run Check* methods will impact the results of the Check*() calls.
It sounds like, in your specific case, this was not intentional.
That said, it can be the intent of the user to impact the Check* methods by doing so.
So it'd be pretty difficult to give a (consistently) useful warning here.
For the time being if you using Environment() without LIBS defined should be a reasonable work around.
Unless you need a library to be linked against all the temporary libraries/programs created by the Check*() logic?

Can I ask you to file a bug on scons.tigris.org<http://scons.tigris.org> with your zip file?
I'll annotate and see if I can create a test case to go in the test suite and see about fixing it.

-Bill

Thanks,
Pawel
From: Bill Deegan [mailto:bill at baddogconsulting.com<mailto:bill at baddogconsulting.com>]
Sent: Tuesday, February 14, 2017 12:38
To: Pawel Winogrodzki <pawelwi at microsoft.com<mailto:pawelwi at microsoft.com>>
Cc: SCons users mailing list <scons-users at scons.org<mailto:scons-users at scons.org>>

Subject: Re: [Scons-users] Using CheckFunc() and CheckLib() breaks dependencies and makes scons ignore file changes

Also see:
http://scons.org/doc/production/HTML/scons-user/ch23s09.html
with regards to ignoring configure checks when running scons -c
-Bill

On Tue, Feb 14, 2017 at 12:36 PM, Bill Deegan <bill at baddogconsulting.com<mailto:bill at baddogconsulting.com>> wrote:
There's the config.log which is where the output from the check* calls is recorded.
(This is also the case with autoconfig whose functionality is being (incompletely in that not all autoconfig checks are implemented, but the output of the builds to config.log is correctly) mimicked)
That is where you go to determine why your configure context checks fail.
And is also the same for autoconfig.
So the cause of this issue was that you were mistakenly linking a library against all libraries and programs being built, and that caused your CheckFunction() to yield the wrong result?
-Bill

On Tue, Feb 14, 2017 at 12:25 PM, Pawel Winogrodzki <pawelwi at microsoft.com<mailto:pawelwi at microsoft.com>> wrote:
No, we’re in the middle of a clean-up and stumbled upon this issue.

Regardless of ones needs I think the Check* calls should not hide building issues from the developers and make scons assume the build was successful. In addition this also prevents scons from picking up files changes and performing a proper cleanup, when ran with the “-c” option.

Thanks,
Pawel

From: Bill Deegan [mailto:bill at baddogconsulting.com<mailto:bill at baddogconsulting.com>]
Sent: Tuesday, February 14, 2017 09:17
To: SCons users mailing list <scons-users at scons.org<mailto:scons-users at scons.org>>
Cc: Pawel Winogrodzki <pawelwi at microsoft.com<mailto:pawelwi at microsoft.com>>
Subject: Re: [Scons-users] Using CheckFunc() and CheckLib() breaks dependencies and makes scons ignore file changes

Any reason you want to have library foo linked against everything you build with your Environment()?
-Bill

On Tue, Feb 14, 2017 at 2:05 AM, Pawel Winogrodzki via Scons-users <scons-users at scons.org<mailto:scons-users at scons.org>> wrote:
Hi all,

I think I found a bug in scons and would like to know, if this is already a known issue, and if so, when could a fix be expected. So far I’ve tried scons 2.5.1 and 2.4.1, and got a repro on both.

Repro steps for Windows, but this also happens on Linux:

  1.  Create a simple Environment object “env”.
  2.  Make it build some library “foo”.
  3.  Call env.Append(LIBS = [‘foo’]).
  4.  Create a Configure object “conf” from “env”.
  5.  Call conf.CheckFunc(‘malloc’) (for instance) and conf.Finish() (unnecessary for the sake of this example).
  6.  Use “env” to build an executable “bar”.

This will make the CheckFunc() call build “foo.lib” while the script is being executed. As long as the lib is built correctly the developer might not notice any issues, but if the lib fails to build scons will indicate that it finished successfully, even though bar.exe is never created. In addition to that any changes to “foo.c” or any other source file, which was compiled by CheckFunc() will not be noticed by scons. Telling scons to explicitly build “foo.lib” will make scons finish successfully without performing any actions, as long as the lib was already built/failed to build in one of the previous runs of scons.

Another side effect is that CheckFunc() will return False, even if the function is available, but the lib failed to build.

In the attachment is a sample scons project showing this behavior. Currently it should build “bar.exe” correctly, but in the output scons will not show any indication, that “foo.lib” has been created. You can find that information inside config.log. If you change anything inside “foo.c”, what would prevent it from compiling correctly, you should see the behavior I’ve described above. Of course make sure to clean up between every build. Calling “scons -c” is not enough – you have to delete all other files generated by scons or at least prevent it from using the cache to determine if a function is present on not.

Again, please let me know, if this is a known issue and how can I handle it (except for removing all CheckFunc() calls).

Thanks,
Pawel Winogrodzki

_______________________________________________
Scons-users mailing list
Scons-users at scons.org<mailto:Scons-users at scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170215/7457fc77/attachment-0001.html>