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

[Bill Deegan]

Looks good.
Thanks!
-=Bill

On Mon, Feb 20, 2017 at 1:32 AM, Pawel Winogrodzki <pawelwi at microsoft.com>
wrote:

> I’ve filed the bug here: http://scons.tigris.org/
> issues/show_bug.cgi?id=3036. I hope I’ve followed all guidelines
> correctly, but please let me know, if something’s unclear/should be fixed.
>
>
>
> Thanks,
>
> Pawel
>
>
>
> *From:* Bill Deegan [mailto:bill at baddogconsulting.com]
> *Sent:* Tuesday, February 14, 2017 17:14
>
> *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
>
>
>
> Pawel,
>
> The bug should be brought to users mailing list: Done
>
> Then if the users group agrees it's a bug, file to scons.tigris.org,
> providing sample to demonstrate the issue.
>
> So ideally you'd make an argument like:   scons FAIL_NOW=yes  which would
> cause it to fail..
>
> If you can also include a log of the build as you did on SO in the bug
> filing that'll help.
>
> I'll add some comments as well once it's filed.
>
> Thanks,
>
> Bill
>
> SCons Project Co-Manager
>
>
>
> On Tue, Feb 14, 2017 at 4:20 PM, Pawel Winogrodzki <pawelwi at microsoft.com>
> wrote:
>
> 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>
> 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/20170220/ef35e400/attachment-0001.html>