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

Tue Feb 14 17:57:28 EST 2017

On Tue, Feb 14, 2017 at 1:00 PM, Pawel Winogrodzki <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 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]
> *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>
> 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>
> 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]
> *Sent:* Tuesday, February 14, 2017 09:17
> *To:* SCons users mailing list <scons-users at scons.org>
> *Cc:* Pawel Winogrodzki <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> 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
> 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/22c4b974/attachment.html>