[Scons-users] Unexpected messge with configure

[Jason Kenny]

Ok, so this is known. I might be looking at changing this in Parts to see what issues this may cause. Normally configure is a different step when a system is generating a build. so this issue does not show up in other systems as they are generating a makefile normally. In this case, I may or may not have run this and have it cached, and for the build to work one may need the results to work. My case at the moment it is more about checking that existing package exists.
To answer the other question. This is is a known problem I have seen as well. When you start making large builds with SCons ( as it generally easier to scale with SCons vs other systems) the load time starts to increase as the node tree has to be constructed. In the case of --help, Scons has two forms of this:
1) -h --help
2) -H --help-options
case 2) is fast as it only prints the help for SCons and nothing else.
case 1) can take longer as SCons needs to load all the files to see if any of them are adding help information. this means the larger the build. The longer the load time before --help will print information.
In my case with Parts I short-circuit this by checking for:
GetOption('help')
if this is set I define the help and then exit. In the case of Parts I just don't load the parts file in my hook after the Sconstruct is read.
In your case using just plan scons you can speed this up by defining some code at the start of the Sconstruct like:
if GetOption('help'):
    define you help text if any
    Return() # don't call Exit() as this prevents the help from printing which might be a different bug
Doing this will greatly speed up the time to get help by avoiding to load all the data files
Jason

________________________________
From: Scons-users <scons-users-bounces at scons.org> on behalf of Bill Deegan <bill at baddogconsulting.com>
Sent: Friday, September 7, 2018 12:20 PM
To: SCons users mailing list
Subject: Re: [Scons-users] Unexpected messge with configure

Mats,

How long does:
scons --help non-existant-target
Take?

-Bill

On Fri, Sep 7, 2018 at 12:26 PM Mats Wichmann <mats at wichmann.us<mailto:mats at wichmann.us>> wrote:
On 09/07/2018 09:55 AM, Jason Kenny wrote:
> I was adding some configure logic to a build I am working on. When doing a dry run i now get this error:
>
> scons: *** Cannot update configure test ".sconf_temp/conftest_0" within a dry-run.
> File "./../scons-3.0.1/SCons/Script/SConscript.py", line 614, in __call__
>
> Is this a known issue with using configure in scons?

I've run into it (you'll find my name on such questions in the mailing
list archive, afair).

When you stop and think about it, running a configure test which means
compiling code sort of doesn't fit the definition of "dry run", though.

this is a gray area to my way of thinking.  steps like cleaning, getting
help, and doing a dry-run are places where you don't want external work
to happen, just have scons go through the rules.  but sometimes you
don't know what all the dependencies actually are before you've run some
of those steps.

we'll wait for the actual experts to pipe up :)

======
Aside:
on the project I'm trying to gradually bend into shape (it had lived for
a couple of years before I came around), which uses a variant directory
build, starting with the variant directory completely absent, "scons
--help" takes seven seconds, and leaves a variant directory with 12
object files and four libraries built. I *KNOW* that's wrong, but I
haven't yet figured out how to fix it without either breaking
everything, or special-casing stuff all over the place like

if not env.GetOption('help') and not env.GetOption('clean'):

guess we could put GetOption('dry-run') in that list too (would we have
to include all of the variants of that name? -n, --no-exec,
--just-print, --dry-run, --recon)

with 200+ sconscripts, adding those cases is not appealing.

_______________________________________________
Scons-users mailing list
Scons-users at scons.org<mailto:Scons-users at scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7Cac30598b56544df2b3c208d614e64625%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636719376578093348&sdata=0FDmS2hg7owLPCyovE2jO%2Ff3dwv%2Fqv6lZaXP397wVGg%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20180907/07c0037d/attachment-0001.html>