[Scons-users] Unexpected messge with configure

[Jason Kenny]

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?

Jason

[Mats Wichmann]

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.

[Bill Deegan]

Mats,

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

-Bill

On Fri, Sep 7, 2018 at 12:26 PM Mats Wichmann <***@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-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Bill Deegan]

Jason,

I'd say it's not a known issue, it's expected behavior.
See the docstring for the exception in question.

What do you think SCons should do in this case?
The dry run would likely be affected by the results of any configure checks
which might write a file or run a process (both things which scons is not
supposed to do with --dry-run), so it's likely not possible to do a dry-run
with configure checks which write to the filesystem?

-Bill

class ConfigureDryRunError(SConfError):
"""Raised when a file or directory needs to be updated during a Configure
process, but the user requested a dry-run"""
def __init__(self,target):
if not isinstance(target, SCons.Node.FS.File):
msg = 'Cannot create configure directory "%s" within a dry-run.' % str
(target)
else:
msg = 'Cannot update configure test "%s" within a dry-run.' % str(target)
SConfError.__init__(self,msg)


On Fri, Sep 7, 2018 at 1:20 PM Bill Deegan <***@baddogconsulting.com>
wrote:

> Mats,
>
> How long does:
> scons --help non-existant-target
> Take?
>
> -Bill
>
> On Fri, Sep 7, 2018 at 12:26 PM Mats Wichmann <***@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-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>

[Jason Kenny]

My first thoughts are that if we can tell if the result is cached to return that value. If there are no cached values do the current behavior. I am not sure how hard this would be however at the moment.
ideally the best behavior I think might be

*
configure item has no cached value. Error as we currently do
*
configure item is cached, return the cached value
*
if we can detect that it has changed and would normally re-execute print a warning message that this is the case and note that the result of the build may change when it really runs
*
Not sure what to do with the cases of configuring items that don't cache ( such as custom functions that the user might have defined in a certain way ).

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

Jason,

I'd say it's not a known issue, it's expected behavior.
See the docstring for the exception in question.

What do you think SCons should do in this case?
The dry run would likely be affected by the results of any configure checks which might write a file or run a process (both things which scons is not supposed to do with --dry-run), so it's likely not possible to do a dry-run with configure checks which write to the filesystem?

-Bill

class ConfigureDryRunError(SConfError):
"""Raised when a file or directory needs to be updated during a Configure
process, but the user requested a dry-run"""
def __init__(self,target):
if not isinstance(target, SCons.Node.FS.File):
msg = 'Cannot create configure directory "%s" within a dry-run.' % str(target)
else:
msg = 'Cannot update configure test "%s" within a dry-run.' % str(target)
SConfError.__init__(self,msg)


On Fri, Sep 7, 2018 at 1:20 PM Bill Deegan <***@baddogconsulting.com<mailto:***@baddogconsulting.com>> wrote:
Mats,

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

-Bill

On Fri, Sep 7, 2018 at 12:26 PM Mats Wichmann <***@wichmann.us<mailto:***@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.

[Jason Kenny]

After a little more testing I see that it works correctly as is. GIven the values are cached it works basically as I suggested above. The message was unclear to me that if it was cached it would be ok.
Jason
________________________________
From: Scons-users <scons-users-***@scons.org> on behalf of Jason Kenny <***@live.com>
Sent: Friday, September 7, 2018 1:10 PM
To: SCons users mailing list
Subject: Re: [Scons-users] Unexpected messge with configure

My first thoughts are that if we can tell if the result is cached to return that value. If there are no cached values do the current behavior. I am not sure how hard this would be however at the moment.
ideally the best behavior I think might be

*
configure item has no cached value. Error as we currently do
*
configure item is cached, return the cached value
*
if we can detect that it has changed and would normally re-execute print a warning message that this is the case and note that the result of the build may change when it really runs
*
Not sure what to do with the cases of configuring items that don't cache ( such as custom functions that the user might have defined in a certain way ).

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

Jason,

I'd say it's not a known issue, it's expected behavior.
See the docstring for the exception in question.

What do you think SCons should do in this case?
The dry run would likely be affected by the results of any configure checks which might write a file or run a process (both things which scons is not supposed to do with --dry-run), so it's likely not possible to do a dry-run with configure checks which write to the filesystem?

-Bill

class ConfigureDryRunError(SConfError):
"""Raised when a file or directory needs to be updated during a Configure
process, but the user requested a dry-run"""
def __init__(self,target):
if not isinstance(target, SCons.Node.FS.File):
msg = 'Cannot create configure directory "%s" within a dry-run.' % str(target)
else:
msg = 'Cannot update configure test "%s" within a dry-run.' % str(target)
SConfError.__init__(self,msg)


On Fri, Sep 7, 2018 at 1:20 PM Bill Deegan <***@baddogconsulting.com<mailto:***@baddogconsulting.com>> wrote:
Mats,

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

-Bill

On Fri, Sep 7, 2018 at 12:26 PM Mats Wichmann <***@wichmann.us<mailto:***@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.

[Mats Wichmann]

On 09/07/2018 12:15 PM, Jason Kenny wrote:
> After a little more testing I see that it works correctly as is. GIven the values are cached it works basically as I suggested above. The message was unclear to me that if it was cached it would be ok.
> Jason

okay, I tried this out (sorry for following up to a message in the
middle of a thread, rather than at the end). with a run in place so
everything should be cached, I still can't dry-run:

$ scons --dry-run
scons: Reading SConscript files ...
Processing using SCons version 3.0.1
Python 2.7.15 (default, May 15 2018, 15:37:31) [GCC 7.3.1 20180303 (Red
Hat 7.3.1-5)] on linux2

scons: *** Cannot update configure test ".sconf_temp/conftest_0.c"
within a dry-run.
File
"/home/mats/iotivity.work/build_common/iotivityconfig/compiler/factory.py",
line 50, in check_for_gcc_c


Should I assume that's a bug in our (homegrown) check, where the
exception was thrown, that it's doing things that even cached results
don't help?

the file in question (that it can't update) is there and is a
bog-standard "test for compiler type" stub of C code.

[Bill Deegan]

Jason,

That seems reasonable, but maybe not simple..

_Bill

On Fri, Sep 7, 2018 at 2:10 PM Jason Kenny <***@live.com> wrote:

> My first thoughts are that if we can tell if the result is cached to
> return that value. If there are no cached values do the current behavior. I
> am not sure how hard this would be however at the moment.
> ideally the best behavior I think might be
>
> - configure item has no cached value. Error as we currently do
> - configure item is cached, return the cached value
> - if we can detect that it has changed and would normally re-execute
> print a warning message that this is the case and note that the result of
> the build may change when it really runs
> - Not sure what to do with the cases of configuring items that
> don't cache ( such as custom functions that the user might have defined in
> a certain way ).
>
> Jason
> ------------------------------
> *From:* Scons-users <scons-users-***@scons.org> on behalf of Bill
> Deegan <***@baddogconsulting.com>
> *Sent:* Friday, September 7, 2018 12:28 PM
> *To:* SCons users mailing list
> *Subject:* Re: [Scons-users] Unexpected messge with configure
>
> Jason,
>
> I'd say it's not a known issue, it's expected behavior.
> See the docstring for the exception in question.
>
> What do you think SCons should do in this case?
> The dry run would likely be affected by the results of any configure
> checks which might write a file or run a process (both things which scons
> is not supposed to do with --dry-run), so it's likely not possible to do a
> dry-run with configure checks which write to the filesystem?
>
> -Bill
>
> class ConfigureDryRunError(SConfError):
> """Raised when a file or directory needs to be updated during a Configure
> process, but the user requested a dry-run"""
> def __init__(self,target):
> if not isinstance(target, SCons.Node.FS.File):
> msg = 'Cannot create configure directory "%s" within a dry-run.' % str
> (target)
> else:
> msg = 'Cannot update configure test "%s" within a dry-run.' % str(target)
> SConfError.__init__(self,msg)
>
>
> On Fri, Sep 7, 2018 at 1:20 PM Bill Deegan <***@baddogconsulting.com>
> wrote:
>
> Mats,
>
> How long does:
> scons --help non-existant-target
> Take?
>
> -Bill
>
> On Fri, Sep 7, 2018 at 12:26 PM Mats Wichmann <***@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-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7C9710a3affd9d4dfcc70d08d614e76e4f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636719381543572547&sdata=QVADywe8YsHd4BMjUt2rj1L%2F2NA3Sku%2F1LN9Sun12vo%3D&reserved=0>
>
> _______________________________________________
> Scons-users mailing list
> Scons-***@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

[Bill Deegan]

Should we change the messaging?
-Bill

On Fri, Sep 7, 2018 at 2:15 PM Bill Deegan <***@baddogconsulting.com>
wrote:

> Jason,
>
> That seems reasonable, but maybe not simple..
>
> _Bill
>
> On Fri, Sep 7, 2018 at 2:10 PM Jason Kenny <***@live.com> wrote:
>
>> My first thoughts are that if we can tell if the result is cached to
>> return that value. If there are no cached values do the current behavior. I
>> am not sure how hard this would be however at the moment.
>> ideally the best behavior I think might be
>>
>> - configure item has no cached value. Error as we currently do
>> - configure item is cached, return the cached value
>> - if we can detect that it has changed and would normally re-execute
>> print a warning message that this is the case and note that the result of
>> the build may change when it really runs
>> - Not sure what to do with the cases of configuring items that
>> don't cache ( such as custom functions that the user might have defined in
>> a certain way ).
>>
>> Jason
>> ------------------------------
>> *From:* Scons-users <scons-users-***@scons.org> on behalf of Bill
>> Deegan <***@baddogconsulting.com>
>> *Sent:* Friday, September 7, 2018 12:28 PM
>> *To:* SCons users mailing list
>> *Subject:* Re: [Scons-users] Unexpected messge with configure
>>
>> Jason,
>>
>> I'd say it's not a known issue, it's expected behavior.
>> See the docstring for the exception in question.
>>
>> What do you think SCons should do in this case?
>> The dry run would likely be affected by the results of any configure
>> checks which might write a file or run a process (both things which scons
>> is not supposed to do with --dry-run), so it's likely not possible to do a
>> dry-run with configure checks which write to the filesystem?
>>
>> -Bill
>>
>> class ConfigureDryRunError(SConfError):
>> """Raised when a file or directory needs to be updated during a Configure
>> process, but the user requested a dry-run"""
>> def __init__(self,target):
>> if not isinstance(target, SCons.Node.FS.File):
>> msg = 'Cannot create configure directory "%s" within a dry-run.' % str
>> (target)
>> else:
>> msg = 'Cannot update configure test "%s" within a dry-run.' % str(target)
>> SConfError.__init__(self,msg)
>>
>>
>> On Fri, Sep 7, 2018 at 1:20 PM Bill Deegan <***@baddogconsulting.com>
>> wrote:
>>
>> Mats,
>>
>> How long does:
>> scons --help non-existant-target
>> Take?
>>
>> -Bill
>>
>> On Fri, Sep 7, 2018 at 12:26 PM Mats Wichmann <***@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-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7C9710a3affd9d4dfcc70d08d614e76e4f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636719381543572547&sdata=QVADywe8YsHd4BMjUt2rj1L%2F2NA3Sku%2F1LN9Sun12vo%3D&reserved=0>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-***@scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>

[Jason Kenny]

Bill,

I think so. I am not sure what the better message would be.
Maybe something like:

No cache data for configure test/directory <test> found
Cannot run action during a dry-run


Jason

From: Scons-users <scons-users-***@scons.org> On Behalf Of Bill Deegan
Sent: Friday, September 7, 2018 1:16 PM
To: SCons users mailing list <scons-***@scons.org>
Subject: Re: [Scons-users] Unexpected messge with configure

Should we change the messaging?
-Bill

On Fri, Sep 7, 2018 at 2:15 PM Bill Deegan <***@baddogconsulting.com<mailto:***@baddogconsulting.com>> wrote:
Jason,

That seems reasonable, but maybe not simple..

_Bill

On Fri, Sep 7, 2018 at 2:10 PM Jason Kenny <***@live.com<mailto:***@live.com>> wrote:
My first thoughts are that if we can tell if the result is cached to return that value. If there are no cached values do the current behavior. I am not sure how hard this would be however at the moment.
ideally the best behavior I think might be

* configure item has no cached value. Error as we currently do

* configure item is cached, return the cached value

* if we can detect that it has changed and would normally re-execute print a warning message that this is the case and note that the result of the build may change when it really runs

* Not sure what to do with the cases of configuring items that don't cache ( such as custom functions that the user might have defined in a certain way ).
Jason
________________________________
From: Scons-users <scons-users-***@scons.org<mailto:scons-users-***@scons.org>> on behalf of Bill Deegan <***@baddogconsulting.com<mailto:***@baddogconsulting.com>>
Sent: Friday, September 7, 2018 12:28 PM
To: SCons users mailing list
Subject: Re: [Scons-users] Unexpected messge with configure

Jason,

I'd say it's not a known issue, it's expected behavior.
See the docstring for the exception in question.

What do you think SCons should do in this case?
The dry run would likely be affected by the results of any configure checks which might write a file or run a process (both things which scons is not supposed to do with --dry-run), so it's likely not possible to do a dry-run with configure checks which write to the filesystem?

-Bill

class ConfigureDryRunError(SConfError):
"""Raised when a file or directory needs to be updated during a Configure
process, but the user requested a dry-run"""
def __init__(self,target):
if not isinstance(target, SCons.Node.FS.File):
msg = 'Cannot create configure directory "%s" within a dry-run.' % str(target)
else:
msg = 'Cannot update configure test "%s" within a dry-run.' % str(target)
SConfError.__init__(self,msg)


On Fri, Sep 7, 2018 at 1:20 PM Bill Deegan <***@baddogconsulting.com<mailto:***@baddogconsulting.com>> wrote:
Mats,

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

-Bill

On Fri, Sep 7, 2018 at 12:26 PM Mats Wichmann <***@wichmann.us<mailto:***@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-***@scons.org<mailto:Scons-***@scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7C9710a3affd9d4dfcc70d08d614e76e4f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636719381543572547&sdata=QVADywe8YsHd4BMjUt2rj1L%2F2NA3Sku%2F1LN9Sun12vo%3D&reserved=0>
_______________________________________________
Scons-users mailing list
Scons-***@scons.org<mailto:Scons-***@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%7Cfc9ee451b05b45f682b608d614ee08b6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636719409907198629&sdata=deG4aNSalcKSY6Q79rrcs4%2F%2FGD%2Fu%2FQPvM7JPRvrD68A%3D&reserved=0>

[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-***@scons.org> on behalf of Bill Deegan <***@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 <***@wichmann.us<mailto:***@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.

[Mats Wichmann]

On 09/07/2018 11:20 AM, Bill Deegan wrote:
> Mats,
>
> How long does:
> scons --help non-existant-target
> Take?
>
> -Bill

the same.

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