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

Tue Feb 14 16:00:50 EST 2017

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.

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”.

Thanks,
Pawel
From: Bill Deegan [mailto:bill at baddogconsulting.com]
Sent: Tuesday, February 14, 2017 12:38
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

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/20170214/e300d093/attachment-0001.html>