[Scons-dev] QMTest where_is different than Environment.py Detect

Bill Deegan bill at baddogconsulting.com
Mon Apr 9 14:19:25 EDT 2018


I've already got a pull request for a more general solution. Not quite done
yet. but with an eye towards resolving appveyor issues as well.
See:
https://github.com/SCons/scons/pull/3052

You can fork my repo and do pull request to add to it?

On Mon, Apr 9, 2018 at 2:00 PM, Daniel Moody <dmoody256 at gmail.com> wrote:

> Im looking at the appveyor environment.
>
> So I should make a pull request for some of those Unix tools to add common
> default paths if sys.platform is win32?
>
> Should I also include in the tests using the path from test.where_is as
> part of the PATH in the generated Sconstruct? If not, is it useful for
> those tests to fail if the tool is in a non-standard location?
>
> On Mon, Apr 9, 2018, 11:57 AM Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>> There is a win32.py in Platform which set's env['PATH']..
>>
>> Also in some cases the individual tools have default paths on win32 to
>> check.
>>
>> What's the path YACC, bison, etc are installed on your system?
>> How did you install them?
>>
>> It may be we need to have some more reasonable defaults for such tools if
>> there is a common/default install path on windows.
>>
>> On Mon, Apr 9, 2018 at 12:43 PM, Daniel Moody <dmoody256 at gmail.com>
>> wrote:
>>
>>> Mostly the Unix tools running on windows environments, e.g YACC, bison,
>>> getext.
>>>
>>> Also for the environments default path, there is the posix.py in
>>> Platform which sets up a default path for linux, but for Windows it relies
>>> on msvs tool to setup an environment. There doesn't seem to be a analogous
>>> posix.py for windows.
>>>
>>>
>>> On Mon, Apr 9, 2018, 11:28 AM Bill Deegan <bill at baddogconsulting.com>
>>> wrote:
>>>
>>>> Depends how it is used.
>>>> If it's used in such a way that the results are then used in a
>>>> generated SConstruct to specify full path to the tools, then the logic
>>>> makes sense.
>>>> If they are used to determine if the test should be run and they yield
>>>> a path which SCons wouldn't natively find, then yes that's not a good way
>>>> to determine if the test should pass.
>>>>
>>>> Are you concerned about some tests in particular which are failing but
>>>> being run due to where_is's behavior?
>>>>
>>>> On Mon, Apr 9, 2018 at 12:16 PM, Daniel Moody <dmoody256 at gmail.com>
>>>> wrote:
>>>>
>>>>> For some of the scons tool tests, the QMTest uses the test where_is
>>>>> method to find the existance of the binary to determine if the test should
>>>>> be run. Then when the test is actually being run, the environment uses it's
>>>>> Detect method to find the binary.
>>>>>
>>>>> The test where_is uses os.environ['PATH'] to search in, but the Detect
>>>>> method does not. This leads to cases where the os environment runtest.py
>>>>> was run under is different than the default environment path that gets set
>>>>> from scons.
>>>>>
>>>>> Should the test where_is work similar to the the environment detect
>>>>> for determining if the test should be run?
>>>>>
>>>>> _______________________________________________
>>>>> Scons-dev mailing list
>>>>> Scons-dev at scons.org
>>>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Scons-dev mailing list
>>>> Scons-dev at scons.org
>>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>>
>>>
>>> _______________________________________________
>>> Scons-dev mailing list
>>> Scons-dev at scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>>
>> _______________________________________________
>> Scons-dev mailing list
>> Scons-dev at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20180409/a3e85ed1/attachment.html>


More information about the Scons-dev mailing list