[Scons-users] Intermiddent build error on Windows - cl : Command line error D8022 : cannot open 'c:\users\admini~1\appdata\local\temp\tmpekylod.lnk'
Shane Gannon
sgannon200 at gmail.com
Thu Sep 8 11:42:46 EDT 2016
Thanks William. That makes sense.
On Thu, Sep 8, 2016 at 4:35 PM, William Blevins <wblevins001 at gmail.com>
wrote:
> Shane,
>
> This is related to the future imports. We may look into trying to support
> both eventually. We aren't ready to release Python3 support fully
> regardless.
>
> V/R,
> William
>
> On Thu, Sep 8, 2016 at 11:00 AM, Shane Gannon <sgannon200 at gmail.com>
> wrote:
>
>> Hi William
>>
>> Based on the error I thought it might be something like that. But I'm
>> using Python 2.7.5 which does support the print 'my text' style.
>>
>> AFAIK it only moved to print('my text') in Python 3.
>>
>> Regards
>> Shane
>>
>> On Thu, Sep 8, 2016 at 3:41 PM, William Blevins <wblevins001 at gmail.com>
>> wrote:
>>
>>> Shane,
>>>
>>> Latest SCons out of development only supports 2.7+ which means requiring
>>> print as a function currently; therefore, you are missing parenthesis.
>>>
>>> V/R,
>>> William
>>>
>>> On Thu, Sep 8, 2016 at 9:06 AM, Shane Gannon <sgannon200 at gmail.com>
>>> wrote:
>>>
>>>> Hi Bill
>>>>
>>>> Actually I made a mistake. Your suggestion
>>>>
>>>> *artifacts = envLocal.SharedLibrary('Library', objFiles)*
>>>>
>>>> does work. Last night I passed the objFiles into a builder for the
>>>> wrong platform. Today, when I noticed the mistake and corrected it, the
>>>> build passed.
>>>>
>>>> I installed the latest development code following the instructions here
>>>>
>>>> https://bitbucket.org/scons/scons
>>>>
>>>> but I got an unusual error
>>>>
>>>>
>>>> print 'my text output'
>>>>
>>>> ^
>>>>
>>>> SyntaxError: invalid syntax
>>>>
>>>> Any ideas?
>>>>
>>>> Regards
>>>> Shane
>>>>
>>>> On Thu, Sep 8, 2016 at 12:32 AM, Bill Deegan <bill at baddogconsulting.com
>>>> > wrote:
>>>>
>>>>> Shane,
>>>>>
>>>>>
>>>>> On Wed, Sep 7, 2016 at 12:00 PM, Shane Gannon <sgannon200 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Bill
>>>>>>
>>>>>> Your suggestion
>>>>>>
>>>>>> *artifacts = envLocal.SharedLibrary('Library', objFiles)*
>>>>>>
>>>>>> makes complete sense. I switched the script over to this. But it did
>>>>>> not fix the problem.
>>>>>>
>>>>>
>>>>> Had small hope it would.
>>>>> Can you try the latest dev code. There was a bunch of patches to use
>>>>> with open().. as x: syntax which should close files faster.
>>>>>
>>>>>
>>>>>>
>>>>>> Why do this rather than using the created shared librarie?
>>>>>>
>>>>>> In these sections of the code the devs want to access and test
>>>>>> internal functions. i.e. Which are not exposed outside the dll. So they
>>>>>> statically link in the object files rather than the dll.
>>>>>>
>>>>>
>>>>> Could they use a windows .lib (static library?)
>>>>>
>>>>> -Bill
>>>>>
>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Shane
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 6:53 PM, Bill Deegan <
>>>>>> bill at baddogconsulting.com> wrote:
>>>>>>
>>>>>>> Shane,
>>>>>>>
>>>>>>> Why don't you do this:
>>>>>>>
>>>>>>> *sources = getAllSources() # Get all the .cpp files*
>>>>>>>
>>>>>>>
>>>>>>> *objFiles = envLocal.Object(sources) # Create a group of .obj files
>>>>>>> from the sources*
>>>>>>>
>>>>>>>
>>>>>>> *artifacts = envLocal.SharedLibrary('Library', objFiles) # Create a
>>>>>>> shared library from the sources*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *envTest['LIBS'].append(objFiles) # Add the .obj files to the link
>>>>>>> path on another environment*
>>>>>>> Why do this rather than using the created shared librarie?
>>>>>>> The obj files are not libraries...
>>>>>>>
>>>>>>> *Or if you want a static library for windows, create a .lib with
>>>>>>> those objects?*
>>>>>>>
>>>>>>>
>>>>>>> *test_sources = getAllSources() # Get all the test .cpp files*
>>>>>>>
>>>>>>> *envTest.Program('TestExecutable', test_sources) # Create a test
>>>>>>> executable which re-uses the .obj files from LIBS on another environment*
>>>>>>> Is the logic above in a second SConscript?
>>>>>>>
>>>>>>> -Bill
>>>>>>>
>>>>>>> On Wed, Sep 7, 2016 at 10:27 AM, Shane Gannon <sgannon200 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> One other update. Might explain the *tempfile_cmdlist* issue som
>>>>>>>> ewhat.
>>>>>>>>
>>>>>>>> I've identified a section of the build where, if I disable it, the
>>>>>>>> build passes when using the standard 2.5.0 release.
>>>>>>>>
>>>>>>>> This part of the build does something a little unusual.
>>>>>>>>
>>>>>>>>
>>>>>>>> *sources = getAllSources() # Get all the .cpp files*
>>>>>>>>
>>>>>>>>
>>>>>>>> *objFiles = envLocal.Object(sources) # Create a group of .obj files
>>>>>>>> from the sources*
>>>>>>>>
>>>>>>>>
>>>>>>>> *artifacts = envLocal.SharedLibrary('Library', sources) # Create a
>>>>>>>> shared library from the sources*
>>>>>>>>
>>>>>>>> *envTest['LIBS'].append(objFiles) # Add the .obj files to the link
>>>>>>>> path on another environment*
>>>>>>>>
>>>>>>>>
>>>>>>>> *test_sources = getAllSources() # Get all the test .cpp files*
>>>>>>>>
>>>>>>>> *envTest.Program('TestExecutable', test_sources) # Create a test
>>>>>>>> executable which re-uses the .obj files from LIBS on another environment*
>>>>>>>>
>>>>>>>> This might cause issues for the *tempfile_cmdlist* check. But
>>>>>>>> there are 3 other sections of the build that do the same thing and they're
>>>>>>>> fine.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 7, 2016 at 4:27 PM, Shane Gannon <sgannon200 at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Bill
>>>>>>>>>
>>>>>>>>> In a local version of SCons 2.5.0 I made the following changes to
>>>>>>>>> SCons/Platform/__init__.py
>>>>>>>>>
>>>>>>>>> # Check if we already created the temporary file for this
>>>>>>>>> target
>>>>>>>>> # It should have been previously done by
>>>>>>>>> Action.strfunction() call
>>>>>>>>> #node = target[0] if SCons.Util.is_List(target) else target
>>>>>>>>> #cmdlist = getattr(node.attributes, 'tempfile_cmdlist',
>>>>>>>>> None) \
>>>>>>>>> # if node is not None else None
>>>>>>>>> #if cmdlist is not None :
>>>>>>>>> # return cmdlist
>>>>>>>>> .........
>>>>>>>>> # Store the temporary file command list into the target
>>>>>>>>> Node.attributes
>>>>>>>>> # to avoid creating two temporary files one for print and
>>>>>>>>> one for execute.
>>>>>>>>> cmdlist = [ cmd[0], prefix + native_tmp + '\n' + rm,
>>>>>>>>> native_tmp ]
>>>>>>>>> #if node is not None:
>>>>>>>>> # try :
>>>>>>>>> # setattr(node.attributes, 'tempfile_cmdlist',
>>>>>>>>> cmdlist)
>>>>>>>>> # except AttributeError:
>>>>>>>>> # pass
>>>>>>>>> return cmdlist
>>>>>>>>>
>>>>>>>>> i.e. I commented out the *tempfile_cmdlist* check.
>>>>>>>>>
>>>>>>>>> The comments lead me to believe this code is a performance fix. I
>>>>>>>>> assumed removing it would not cause breaks.
>>>>>>>>>
>>>>>>>>> That seems to be the case. SCons did not break. Plus now my build
>>>>>>>>> succeeds.
>>>>>>>>>
>>>>>>>>> I'd guess that SCons is setting this attribute on a node. But that
>>>>>>>>> node is being used more than once in our build (really not sure if this is
>>>>>>>>> possible). When the node is first used tempfile_cmdlist is created as well
>>>>>>>>> as the temp file. But when it is re-used it detects that 'tempfile_cmdlist'
>>>>>>>>> already exists and does not bother to create a second temp file.
>>>>>>>>>
>>>>>>>>> Is that possible? What would make it specific to our build? i.e.
>>>>>>>>> Otherwise I assume more people would have reported this problem.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Shane
>>>>>>>>>
>>>>>>>>> On Wed, Sep 7, 2016 at 3:26 PM, Bill Deegan <
>>>>>>>>> bill at baddogconsulting.com> wrote:
>>>>>>>>>
>>>>>>>>>> Shane,
>>>>>>>>>>
>>>>>>>>>> I didn't see any change in the logic which opens, writes, or
>>>>>>>>>> closes the tmp files in those commits.
>>>>>>>>>> Only in the way it's used by mslink, and msvc and some messaging
>>>>>>>>>> and another test.
>>>>>>>>>>
>>>>>>>>>> -Bill
>>>>>>>>>>
>>>>>>>>>> On Wed, Sep 7, 2016 at 6:52 AM, Shane Gannon <
>>>>>>>>>> sgannon200 at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi William
>>>>>>>>>>>
>>>>>>>>>>> To be truthful I don't have the expertise to rule out SCon
>>>>>>>>>>> 2.3.4. But we have run thousands of builds on it without issue. In
>>>>>>>>>>> constrast on 2.5.0 (and to a lesser extent 2.3.6 & 2.3.5) we can fully
>>>>>>>>>>> reproduce this problem.
>>>>>>>>>>>
>>>>>>>>>>> That suggests an edge condition was introduced by 2.3.5. I took
>>>>>>>>>>> a look back through the commit history and came across
>>>>>>>>>>>
>>>>>>>>>>> https://bitbucket.org/scons/scons/commits/bad59be7270dbbe62c
>>>>>>>>>>> 7868a532fad84480f95fae
>>>>>>>>>>> https://bitbucket.org/scons/scons/commits/9aa37cd21e99eb684a
>>>>>>>>>>> b6ae8f7b21e0a71751ac7f
>>>>>>>>>>> https://bitbucket.org/scons/scons/commits/da5785c5f30f852734
>>>>>>>>>>> b3f985b798a5508bfea9db
>>>>>>>>>>>
>>>>>>>>>>> which are consequetive commits by the same author
>>>>>>>>>>> (LaurentMarchelli). He was working on the SCons/Platform/__init__.py file
>>>>>>>>>>> and the TempFileMunge class. This is the class that creates the .lnk files.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Shane
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Sep 7, 2016 at 2:16 PM, William Blevins <
>>>>>>>>>>> wblevins001 at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Shane,
>>>>>>>>>>>>
>>>>>>>>>>>> We can look into that specific revision, but if this is a race
>>>>>>>>>>>> condition, then it's possible that this is a problem in other versions. It
>>>>>>>>>>>> doesn't make much sense that the issue is not reproducible in version 2.4.0
>>>>>>>>>>>> unless there was a missing patch that was reapplied (which is unlikely but
>>>>>>>>>>>> not impossible).
>>>>>>>>>>>>
>>>>>>>>>>>> V/R,
>>>>>>>>>>>> William
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Sep 7, 2016 at 8:30 AM, Shane Gannon <
>>>>>>>>>>>> sgannon200 at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I've been testing out some scenarios and here is what I
>>>>>>>>>>>>> discovered
>>>>>>>>>>>>>
>>>>>>>>>>>>> SCons 2.5.0 with vs2013 - Reproduced the problem
>>>>>>>>>>>>>
>>>>>>>>>>>>> SCons 2.3.6 with vs2013 - Reproduced the problem
>>>>>>>>>>>>>
>>>>>>>>>>>>> SCons 2.3.5 with vs2013 - Reproduced the problem
>>>>>>>>>>>>>
>>>>>>>>>>>>> SCons 2.5.0 with vs2013 on Windows 7 - Reproduced the problem
>>>>>>>>>>>>>
>>>>>>>>>>>>> SCons 2.4.0 on both Windows 10 & Window 7 - *Problem not
>>>>>>>>>>>>> reproduced*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Seems this bug was introduced by Scons 2.3.5.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Sep 7, 2016 at 11:19 AM, Shane Gannon <
>>>>>>>>>>>>> sgannon200 at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Bill Deegan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Both the 2013 & 2015 builders use Windows version 10.0.102540
>>>>>>>>>>>>>> Build 10240.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Windows Defender is disabled on the build machines. We took
>>>>>>>>>>>>>> the attitude that anti-virus protection was a waste of resources. Plus it
>>>>>>>>>>>>>> introduced unwanted variability to build speed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The Windows Search Indexing Service was enabled. But, after
>>>>>>>>>>>>>> disabling it, the problem persisted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tested out SCons 2.5.0 with vs2013. It reproduced the
>>>>>>>>>>>>>> problem. So this issue may have been introduced since SCons 2.3.4.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Arvid Rosén
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Good suggestion. But we use ActivePython which has pywin32
>>>>>>>>>>>>>> built into it. Verified that with pip list.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Sep 7, 2016 at 8:20 AM, Arvid Rosén <
>>>>>>>>>>>>>> arvid at softube.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Do you have pywin32 installed btw?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Arvid
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 07 Sep 2016, at 01:27, Bill Deegan <
>>>>>>>>>>>>>>> bill at baddogconsulting.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Are you also upgrading your version of windows?
>>>>>>>>>>>>>>> Do you see the problem with scons 2.5.0 and MSVC 2013?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is not a known issue.
>>>>>>>>>>>>>>> However as Arvid said.. it can be related to Windows
>>>>>>>>>>>>>>> Defender and Search Indexing.
>>>>>>>>>>>>>>> Perhaps you can disable search indexing and see if it has
>>>>>>>>>>>>>>> any impact?
>>>>>>>>>>>>>>> You might try disabling windows defender for a short test as
>>>>>>>>>>>>>>> well... (though I wouldn't advise doing so in an insecure environment or
>>>>>>>>>>>>>>> for a long period of time..)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Sep 6, 2016 at 9:59 AM, Shane Gannon <
>>>>>>>>>>>>>>> sgannon200 at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi all
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm in the process of upgrading a Windows build machine.
>>>>>>>>>>>>>>>> It's tool set is moving to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Visual Studio 2015 Update 3
>>>>>>>>>>>>>>>> - scons 2.5.0
>>>>>>>>>>>>>>>> - msbuild 14.0.25420.1
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Visual Studio 2013 Update 4
>>>>>>>>>>>>>>>> - scons 2.3.4
>>>>>>>>>>>>>>>> - msbuild 12.0.31101
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But I'm getting an unexpected error.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *cl : Command line error D8022 : cannot open
>>>>>>>>>>>>>>>> 'c:\users\admini~1\appdata\local\temp\tmpekylod.lnk'*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This can occur once or multiple times in the first clean
>>>>>>>>>>>>>>>> build. i.e. With each occurence for a different file name. But if I then
>>>>>>>>>>>>>>>> run a rebuild the problem resolves itself.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The .lnk file seems to be SCons specific. It's created in
>>>>>>>>>>>>>>>> the temp folder and contains something like
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> */nologo /DEBUG /dynamicbase /fixed:no /OPT:REF /OPT:ICF
>>>>>>>>>>>>>>>> -ignore:4042 -ignore:4042 -ignore:4099 /nologo /DEBUG /dynamicbase
>>>>>>>>>>>>>>>> /fixed:no /OPT:REF /OPT:ICF -ignore:4042 /dll /out:mylibrary.dll .......*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> i.e. The command to execute.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Windows *cl* eats this up with
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *cl @c:\users\admini~1\appdata\local\temp\tmpekylod.lnk*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and executes with the parameters found in the .lnk file.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> AFAIK this behaviour has existed in SCons since version 0.9.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> See
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://www.scons.org/CHANGES.txt
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *RELEASE 0.90 - Wed, 25 Jun 2003 14:24:52 -0500*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * - Use '.lnk' as the suffix on the temporary file for linking long
>>>>>>>>>>>>>>>> command lines (necessary for the Phar Lap linkloc linker).*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But, for some reason reason, *some* .lnk files are not generated in time for me. Hence the build fails.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is this a known issue? Has it been introduced since scons 2.3.4? Is there any work around?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I should mention that my builder
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Is a Windows 10 machine
>>>>>>>>>>>>>>>> - Has 20 cpu cores and runs scons -j 20
>>>>>>>>>>>>>>>> - Has 25Gb of RAM
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There may be a parallization problem here. But it is not an issue for the current build (which also uses -j 20). I experimented with using -j 10 but the problem persisted.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I also choose to build only a sub-set of the projects. i.e. I excluded the tests. This allowed the build to pass.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Any thoughts/suggestions?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Shane
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Scons-users mailing list
>>>>>>>>>>>>>>>> Scons-users at scons.org
>>>>>>>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Scons-users mailing list
>>>>>>>>>>>>>>> Scons-users at scons.org
>>>>>>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Scons-users mailing list
>>>>>>>>>>>>>>> Scons-users at scons.org
>>>>>>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Scons-users mailing list
>>>>>>>>>>>>> Scons-users at scons.org
>>>>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Scons-users mailing list
>>>>>>>>>>>> Scons-users at scons.org
>>>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Scons-users mailing list
>>>>>>>>>>> Scons-users at scons.org
>>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Scons-users mailing list
>>>>>>>>>> Scons-users at scons.org
>>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Scons-users mailing list
>>>>>>>> Scons-users at scons.org
>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Scons-users mailing list
>>>>>>> Scons-users at scons.org
>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-users at scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-users at scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-users at scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-users at scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
> _______________________________________________
> 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/20160908/3467e0b2/attachment-0001.html>
More information about the Scons-users
mailing list