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

[Bill Deegan]

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/b7efa6f8/attachment.html>