Re: [Scons-dev] SCons and Clang

[Alexandre Feblot]

Hi there,

Would this only support compiling with clang, or would you also intend in
some ways to handle clang static analysis tool (scan-build wrapper which
btw can use clang or gcc as a compiler)?

2017-06-21 15:15 GMT+02:00 Jason Kenny :

> I 100% agree.
>
> I have a tool in Parts here: https://bitbucket.org/sconsparts/parts/src/
> 6a57ea6ae48acf491cda5ab8c1d45fd53d4543c2/parts/tools/clang.
> py?at=master=file-view-default
>
> There are some different options that can show up and a great options to
> have ( given we have some better configuration support in SCons ) is to
> have added the to force color output. This is also true for gcc in newer
> versions. The force of color allows for the useful and pretty output that
> clang provides to the users, that is turned off otherwise, because we are
> redirecting text output through a pipe
>
> Jason
>
> -Original Message-
> From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Russel
> Winder
> Sent: Wednesday, June 21, 2017 6:22 AM
> To: SCons_Developers 
> Subject: [Scons-dev] SCons and Clang
>
> For SCons 3.0 we really ought to have clang and clang++ tools as standard
> out of the box with no hacking needed. As I understand it, Clang follows
> GCC command line options, though I guess there are variations. So as a
> first stab, I'll create clang.py and clang++.py by copying and amending
> gcc.py and
> g++.py.
>
> Assuming someone hasn't already done this, and assuming no-one can see a
> fault with the line of reasoning.
>
> --
> Russel.
> 
> =
> Dr Russel Winder t:+44 20 7585 2200   voip:sip:
> russel.win...@ekiga.net
> 41 Buckmaster Road   m:+44 7770 465 077   xmpp:rus...@winder.org.uk
> London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Alexandre Feblot]

Tim, yes, I misread you, thanks for the clarification.
Ok, saved for this time.
--
Alexandre Feblot

> Le 26 mai 2016 à 01:24, Tim Jenness <tjenn...@lsst.org> a écrit :
> 
> 
>> On May 25, 2016, at 16:13, Alexandre Feblot <alexan...@feblot.fr> wrote:
>> 
>> 
>> 
>> Obviously, not introducing any "api break" would be the best, but I don't 
>> see where Tim suggests a solution. Tim wrote about "removing print 
>> statements from his SConscripts", which is exactly the painful case I 
>> described.
>> 
> 
> I don’t think I suggested that. I (thought I) was suggesting that the code in 
> scons that loads the SConscript files should not itself include any print 
> statements so that there would be no need to enable print_function in that 
> file.
> 
> For simple prints in that file you also have the option of doing
> 
> print(some_string)
> 
> which works on both 2.7 and 3.x regardless because in 2.7 those parentheses 
> disappear. It’s only when commas start turning up that you need 
> print_function enabled.
> 
> — 
> Tim Jenness
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Alexandre Feblot]

So, here we are, we get an incompatibility with existing product build systems 
based on current scons, and thus, the need to support multiple versions of 
scons installed on the same machine, so we can keep compiling all old 
maintenance branches and all old tags of our products without having to fix all 
of them?

 
--
Alexandre Feblot

> Le 25 mai 2016 à 23:47, Tim Jenness <tjenn...@lsst.org> a écrit :
> 
>> 
>> On May 25, 2016, at 14:38, Bill Deegan <b...@baddogconsulting.com 
>> <mailto:b...@baddogconsulting.com>> wrote:
>> 
>> Tim,
>> 
>> Here's the implementation:
>> https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default=file-view-default#SConscript.py-251
>>  
>> <https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default=file-view-default#SConscript.py-251>
>> 
>> Basically it exec()'s the SConscript as follows:
>>  <>exec(compile(_file_.read(), _file_.name, 
>> 'exec'),
>>  <> call_stack[-1].globals)
>> 
>> So given that print_function() is already imported from __future__ at that 
>> point I don't think we can do a per SConscript exclusion?
>> 
> 
> Right. It compiles a string so print_function is in effect.
> 
> I think what I’d do is ban the use of print in that file so that the 
> print_function directive is not active. There are only two prints in there so 
> I’d move those two routines to a different file or provide a utility print 
> routine from somewhere else that those functions use.
> 
> — 
> Tim Jenness
> 
> 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org <mailto:Scons-dev@scons.org>
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> <https://pairlist2.pair.net/mailman/listinfo/scons-dev>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] pip install scons

[Alexandre Feblot]

2016-05-12 11:06 GMT+02:00 anatoly techtonik <techto...@gmail.com>:

> On Fri, May 6, 2016 at 2:18 PM, Alexandre Feblot <alexan...@feblot.fr>
> wrote:
> > Hi,
> >
> > Supporting multiple versions at the same time will be required as soon
> as a
> > SCons release breaks compatibility. If you want your older product
> sources
> > built with an old SCons to keep building, you need to keep this old Scons
> > available for them.
>
> And what `scons` binary should refer to then?
>

Should this happen, I guess I'd keep scons being the old one, for
compatibility reasons, and would name the new one scons3.0 for example, and
would update my project build system to use scons3.0 in the current branch.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Trial SCons migration to git on github

[Alexandre Feblot]

If I look at the branch pchdll in which 2 commits were done, githib doesn't 
show anything before those commits. This seems wrong.
https://bitbucket.org/scons/scons/commits/branch/pchdll 
<https://bitbucket.org/scons/scons/commits/branch/pchdll>
https://github.com/bdbaddog/scons-gh-migrate/commits/pchdll 
<https://github.com/bdbaddog/scons-gh-migrate/commits/pchdll>

Focusing on the first commit (VC11 needs PCH objects added to the link line.):
https://bitbucket.org/scons/scons/commits/552d60649cdbfc46979a493fb0d8a8618c892f79?at=pchdll
 
<https://bitbucket.org/scons/scons/commits/552d60649cdbfc46979a493fb0d8a8618c892f79?at=pchdll>
https://github.com/bdbaddog/scons-gh-migrate/commit/4de52be091f23e3b8c8e0027bd1d27b6bec92ef9
 
<https://github.com/bdbaddog/scons-gh-migrate/commit/4de52be091f23e3b8c8e0027bd1d27b6bec92ef9>

Bitbucket properly shows the single change in src/engine/SCons/Tool/mslink.py, 
whereas github seems to think that all files are just added to an empty project 
(making it impossible to see the actual change).

Conclusion: It looks like there is an issue with where branches are created 
from.

--
Alexandre Feblot

> Le 6 janv. 2016 à 20:28, William Blevins <wblevins...@gmail.com> a écrit :
> 
> It looks right at a glance.
> 
> On Wed, Jan 6, 2016 at 7:03 PM, Bill Deegan <b...@baddogconsulting.com 
> <mailto:b...@baddogconsulting.com>> wrote:
> All,
> 
> I wanted to see how hard this would be.
> Pretty simple. Github has a migrator which did all the work.
> If anyone wants to take a look and see if they find any issues with the 
> migration take a look here
> https://github.com/bdbaddog/scons-gh-migrate 
> <https://github.com/bdbaddog/scons-gh-migrate>
> -Bill
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org <mailto:Scons-dev@scons.org>
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> <https://pairlist2.pair.net/mailman/listinfo/scons-dev>
> 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] That was easy…

[Alexandre Feblot]

Hi,
If SCons should move to using pip to be installed, I do hope there would still 
be as well a simple archive delivery.
We try to keep our servers with as little installed softwares/packages as 
possible, and adding the need to take care of having a working pip on every 
linux/aix/solaris/windows server would be an additional hassle.
Also, I suppose pip would make life harder for projects that need to compile on 
servers with no internet access.



> Le 27 déc. 2015 à 18:02, Jason Kenny  a écrit :
> 
> In the current form yes.
>  
> We can use features in pip to get the packages and install them in a 
> directory contained within the src-local area of scons and modify the startup 
> script to add a python path to the packages. This can be zipped up and used 
> to solve this problem. I did something like this for one of my last projects 
> at Intel.
>  
> Jason
> 
> From: Bill Deegan 
> Sent: Saturday, December 26, 2015 9:23 PM
> To: SCons developer list 
> Subject: Re: [Scons-dev] That was easy…
>  
> The only question is would this break the scons-local distributions?
>  
> On Sat, Dec 26, 2015 at 6:13 PM, Jason Kenny  > wrote:
> +1
> 
> Sent from my Windows Phone
> 
> -Original Message-
> From: "Bill Deegan"  >
> Sent: ‎12/‎26/‎2015 7:00 PM
> To: "SCons developer list" >
> Subject: Re: [Scons-dev] That was easy…
> 
> If we change to suggesting pip/easy_install to be the preferred method of 
> installing, then we can include any other packages we need and not have to 
> "Vendorize" them.
> 
> 
> 
> On Sat, Dec 26, 2015 at 9:19 AM, Russel Winder  > wrote:
> 
> On Fri, 2015-12-25 at 13:15 -0500, Neal Becker wrote:
> >
> […]
> >
> > I should have said, I don't think we can make installing future a
> > requirement for using scons.
> >
> > In my case, I was using lineprofiler.  It does something strange
> > with
> > builtins, and the reason lineprofiler mysteriously stopped working
> > after
> > future was installed was hard to find.
> 
> So the consequence of this is that we can only go to a level 1 futurize
> and then the rest needs to be manually hacked so that there is no
> future dependency? I suspect this means we will end up rewriting quite
> a chunk of future, though not the bits needed for Python 2.6.
> 
> 
> --
> Russel.
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net 
> 
> 41 Buckmaster Roadm: +44 7770 465 077    
> xmpp: rus...@winder.org.uk 
> London SW11 1EN, UK   w: www.russel.org.uk   
> skype: russel_winder
> 
> 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org 
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org 
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> 
>  
>  
> ___
> Scons-dev mailing list
> Scons-dev@scons.org 
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> 
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Unit testing with mock?

[Alexandre Feblot]

Hi,
Please, please, please, 
Don't!
Don't force people to install additional modules. 
One of Python benefits is how rich its standard distribution is, compared to 
perl for example, allowing to distribute code that you know will work 
everywhere without additional requirement. 
Please don't break that. 

Alexandre

> Le 22 oct. 2015 à 23:58, Pawel Tomulik  a écrit :
> 
> Hi,
> 
> If I would like to contribute a module to scons, would it be acceptable
> to use mocks (https://pypi.python.org/pypi/mock) in unit tests? From
> what I see, none of the existsing unit tests in SCons use mocks, perhaps
> for a reason? Is it forbidden? Is there an alternative without using the
> module?
> 
> The mock module is not included in the basic python distribution, it has
> to be installed, for example with pip (it's a backport of unittest.mock
> available in python >=3.3).
> 
> 
> Best regards!
> 
> -- 
> Paweł Tomulik
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons.. the road ahead

[Alexandre Feblot]

Hi,
Wasn't Dirk speaking of first cleaning some 2.6-ish code?

--
Alexandre Feblot

> Le 26 sept. 2015 à 00:02, William Blevins <wblevins...@gmail.com> a écrit :
> 
> 
> 
> On Fri, Sep 25, 2015 at 10:57 PM, Bill Deegan <b...@baddogconsulting.com 
> <mailto:b...@baddogconsulting.com>> wrote:
> 
> 
> On Fri, Sep 25, 2015 at 2:50 PM, William Blevins <wblevins...@gmail.com 
> <mailto:wblevins...@gmail.com>> wrote:
> 
> 
> On Fri, Sep 25, 2015 at 10:40 PM, Bill Deegan <b...@baddogconsulting.com 
> <mailto:b...@baddogconsulting.com>> wrote:
> Greetings,
> 
> Here's what I'm thinking (Note I'm explicitly not discussing any 
> infrastructure changes here, bugtracker, git vs hg, etc, so please do not 
> chime in in this thread on those issues)
> 
> 1) Merge any fairly trivial pull requests currently outstanding to default 
> branch
> 2) Release 2.4.1 (And push to pypi)
> 3) Merge cross language scanner pull request.
> 4) Release 2.5.0 (and push to pypi)
> 
> I follow you up to here.
>  
> 5) Merge 3.0 branch to default and finish that once and for all. 
> 
> Is this part high risk?  I assume that the 3.0 branch is still 2.7 compliant. 
>  If it is then, it should be fine.
> 
> Yes the codebase should be Python 2.7.x and 3.x compat (where x is TBD but 
> most likely .10 and .3? respectively).
>  No Python 3.x only SCons for the foreseeable future, at least in my mind. 
> Enough people are stuck at that with platforms they need to support for a 
> while.
> 
> 
> Then I don't see any issues with this path forward. 
>  
>  
> 6) Release a beta for 3.0
> 7) Release 3.0
> 
> Thoughts?
> 
> -Bill
> SCons Project Co-Manager
> 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org <mailto:Scons-dev@scons.org>
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> <https://pairlist2.pair.net/mailman/listinfo/scons-dev>
> 
> 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org <mailto:Scons-dev@scons.org>
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> <https://pairlist2.pair.net/mailman/listinfo/scons-dev>
> 
> 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org <mailto:Scons-dev@scons.org>
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> <https://pairlist2.pair.net/mailman/listinfo/scons-dev>
> 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org <mailto:Scons-dev@scons.org>
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> <https://pairlist2.pair.net/mailman/listinfo/scons-dev>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Updated work in progress SCons.org

[Alexandre Feblot]

 http://scons.org/doc/1.3.1/HTML/scons-api/SCons.Memoize.A-class.htmlAhttp://scons.org/doc/1.3.1/HTML/scons-api/SCons.Memoize-pysrc.html
404 http://scons.org/doc/1.3.1/HTML/scons-api/SCons.compat._scons_subprocess.STARTUPINFO-class.htmlSTARTUPINFOhttp://scons.org/doc/1.3.1/HTML/scons-api/SCons.compat._scons_subprocess-pysrc.html
404 http://scons.org/doc/1.3.1/HTML/scons-api/SCons.compat._scons_subprocess.pywintypes-class.htmlpywintypeshttp://scons.org/doc/1.3.1/HTML/scons-api/SCons.compat._scons_subprocess-pysrc.html
404 http://scons.org/doc/1.3.0/HTML/scons-api/SCons.Memoize.M-class.htmlMhttp://scons.org/doc/1.3.0/HTML/scons-api/SCons.Memoize-pysrc.html
404 http://scons.org/doc/1.3.0/HTML/scons-api/SCons.Memoize.A-class.htmlAhttp://scons.org/doc/1.3.0/HTML/scons-api/SCons.Memoize-pysrc.html
404 http://scons.org/doc/1.3.0/HTML/scons-api/SCons.PathList.PathListCache-class.htmlPathListCachehttp://scons.org/doc/1.3.0/HTML/scons-api/SCons.PathList-pysrc.html
404 http://scons.org/doc/1.3.0/HTML/scons-api/SCons.compat._scons_subprocess.STARTUPINFO-class.htmlSTARTUPINFOhttp://scons.org/doc/1.3.0/HTML/scons-api/SCons.compat._scons_subprocess-pysrc.html
404 http://scons.org/doc/1.3.0/HTML/scons-api/SCons.compat._scons_subprocess.pywintypes-class.htmlpywintypeshttp://scons.org/doc/1.3.0/HTML/scons-api/SCons.compat._scons_subprocess-pysrc.html
404 http://scons.org/doc/1.2.0/HTML/scons-api/SCons.Memoize.M-class.htmlMhttp://scons.org/doc/1.2.0/HTML/scons-api/SCons.Memoize-pysrc.html
404 http://scons.org/doc/1.2.0/HTML/scons-api/SCons.Memoize.A-class.htmlAhttp://scons.org/doc/1.2.0/HTML/scons-api/SCons.Memoize-pysrc.html
404 http://scons.org/doc/1.2.0/HTML/scons-api/SCons.PathList.PathListCache-class.htmlPathListCachehttp://scons.org/doc/1.2.0/HTML/scons-api/SCons.PathList-pysrc.html
404 http://scons.org/doc/2.1.0/HTML/scons-api/SCons.PathList.PathListCache-class.htmlPathListCachehttp://scons.org/doc/2.1.0/HTML/scons-api/SCons.PathList-pysrc.html
404 http://scons.org/doc/2.1.0/HTML/scons-api/SCons.compat._scons_subprocess.STARTUPINFO-class.htmlSTARTUPINFOhttp://scons.org/doc/2.1.0/HTML/scons-api/SCons.compat._scons_subprocess-pysrc.html
404 http://scons.org/doc/2.1.0/HTML/scons-api/SCons.compat._scons_subprocess.pywintypes-class.htmlpywintypeshttp://scons.org/doc/2.1.0/HTML/scons-api/SCons.compat._scons_subprocess-pysrc.html
404 http://scons.org/doc/2.0.0.final.0/HTML/scons-api/SCons.PathList.PathListCache-class.htmlPathListCachehttp://scons.org/doc/2.0.0.final.0/HTML/scons-api/SCons.PathList-pysrc.html
404 http://scons.org/doc/2.0.0.final.0/HTML/scons-api/SCons.compat._scons_subprocess.STARTUPINFO-class.htmlSTARTUPINFOhttp://scons.org/doc/2.0.0.final.0/HTML/scons-api/SCons.compat._scons_subprocess-pysrc.html
404 http://scons.org/doc/2.0.0.final.0/HTML/scons-api/SCons.compat._scons_subprocess.pywintypes-class.htmlpywintypeshttp://scons.org/doc/2.0.0.final.0/HTML/scons-api/SCons.compat._scons_subprocess-pysrc.html


Check your sites automatically and regularly with the DeadLinkChecker Auto-Checker - Upgrade now.

--Alexandre Feblot

Le 11 août 2015 à 01:13, Bill Deegan b...@baddogconsulting.com a écrit :Jonathon,Good suggestions.Not sure what's causing the news drop down to be screwy. I'm customizing the pelican-bootstrap theme for pelican to get the pull down menus.I'll see what I can do.-BillOn Mon, Aug 10, 2015 at 4:00 PM, Jonathon Reinhart jonathon.reinh...@gmail.com wrote:Looking good!Notes:* "Releases" drop-down menu overflows vertically - Not sure the best way to handle this. Maybe clip it at 10 entries, and have a "More..." at the bottom that goes to a page with all releases listed?* "News" drop-down menu seems to be buggy. It's emitting entries that look like this:lia href=""http://scons.org/new/scons-awarded-two-projects-for-google-summer-of-code-2007.html" target="_blank" class="">http://scons.org/new/scons-awarded-two-projects-for-google-summer-of-code-2007.html"Scons awarded two projects for google /aa class="reference internal" href=""summer of code/a 2007/li* Perhaps the Twitter icon should be changed to the SCons logo?Jonathon Reinhart
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

___Scons-dev mailing listScons-dev@scons.orghttps://pairlist2.pair.net/mailman/listinfo/scons-dev___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Patch for potential new debug option

[Alexandre Feblot]

Hi,
would have this been available, I indeed would already have used scons 
--envdump=CXXFLAGS,CFLAGS,ENV.PATH A.o

--
Alexandre Feblot

 Le 8 août 2015 à 15:04, William Blevins wblevins...@gmail.com a écrit :
 
 I guess I should be a bit more explicit about what I am trying to do.
 
 Example:
 A.cpp
 SConstruct - Program( 'exe', Glob( '*.cpp' ) )
 
 My goal original goal was to be able to print environment objects from the 
 command-line without having to modify code:
 1. As written: [Example: scons --debug=envdump A.o would print the build 
 environment object assigned to A.o ].
 2. Afterthought on usability: [Example: scons --envdump=LIBS A.o would 
 print the variable LIBS from the build environment assigned to A.o].
 2.1 Since environment objects are rather large, maybe printing just a single 
 value from the environment object would be more readable and/or desired on a 
 regular basis.
 
 The supplied patch works for Case 1, but I am having a hard time getting only 
 the targets on the command-line.  Currently, the patch prints the environment 
 for all targets on the command-line, plus all their dependencies (as long as 
 they have build environments) and I am hoping to not print their dependencies.
 
 [Example: scons --debug=envdump A.o would print the environment for target 
 A.o but not A.cpp or /usr/bin/g++ because they don't have a build 
 environment.]
 
 [Example: scons --debug=envdump exe would print the environment for target 
 exe plus A.o because it's in the target list (as a dependency of exe)]
 
 If I can figure out a clean way to get only the targets on the command-line, 
 then that makes the most sense.  The real question is do we want Case 1, Case 
 2,or both capabilities?
 
 V/R,
 William
 
 
 
 
 
 On Sat, Aug 8, 2015 at 3:42 AM, Roberto De Vecchi 
 roberto.devec...@vi-grade.com mailto:roberto.devec...@vi-grade.com wrote:
 William,
 
 from my experience using varname as a filter to limit the output will not 
 help much in big trees where my cloned env are assigned to vars with the same 
 name.
 
 I would find very useful having the env dump limited to the target node 
 specified on the command line: is this already supported by your proposal?
 
 Roberto
 
 --- Messaggio Originale ---
 Da:   William Blevins wblevins...@gmail.com mailto:wblevins...@gmail.com
 Data: 08 Agosto 2015 07:22:12
 Oggetto:  [Scons-dev] Patch for potential new debug option
 A:SCons developer list scons-dev@scons.org mailto:scons-dev@scons.org
 
 Here is a patch for dumping build environments via the command-line.
 
 I couldn't ever figure out a good way to get only explicitly lister targets 
 (non-default commandline targets).  It will essentially print the 
 node.get_env().Dump() for all targets with a build_env defined.
 
 I could potentially change it from --debug=envdump to something like 
 --envdump=VARIABLE so that it could print a particular variable rather 
 than the whole env.
 
 Does this interest anyone or waste of chars?
 
 diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
 --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
 +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
 @@ -391,6 +391,21 @@
  def prepare(self):
  pass
  
 +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
 +SCons task for --debug=envdump.  Prints env dump for 
 BUILD_TARGETS.
 +def prepare(self):
 +pass
 +
 +def execute(self):
 +for target in self.targets:
 +if target.get_build_env():
 +print 'Environment dump for target: ' + str(target)
 +print target.get_env().Dump()
 +
 +def executed(self):
 +pass
 +
 +
  class QuestionTask(SCons.Taskmaster.AlwaysTask):
  An SCons task for the -q (question) option.
  def prepare(self):
 @@ -657,6 +672,7 @@
  if memory in debug_values:
  memory_stats.enable(sys.stdout)
  print_objects = (objects in debug_values)
 +options.debug_envdump = ( envdump in debug_values )
  if print_objects:
  SCons.Debug.track_instances = True
  if presub in debug_values:
 @@ -1210,8 +1226,13 @@
  failure_message = done building targets (errors occurred during 
 build).
  else:
  failure_message = building terminated because of errors.
 +
 +if options.debug_envdump:
 +task_class = EnvDumpTask
 +
  if options.question:
  task_class = QuestionTask
 +
  try:
  if options.clean:
  task_class = CleanTask
 diff -r 682b8a7a51fb src/engine/SCons/Script/SConsOptions.py
 --- a/src/engine/SCons/Script/SConsOptions.pyMon Jun 29 15:37:44 2015 
 -0400
 +++ b/src/engine/SCons/Script/SConsOptions.pyThu Aug 06 23:44:50 2015 
 -0400
 @@ -673,7 +673,7 @@
  tree  : '; please use --tree=all instead',
  }
  
 -debug_options = [count, duplicate, explain, findlibs,
 +debug_options = [count, duplicate, explain, envdump

Re: [Scons-dev] Patch for potential new debug option

[Alexandre Feblot]

Would a standard shell redirection not be enough?
--
Alexandre Feblot

 Le 8 août 2015 à 17:38, Bill Deegan b...@baddogconsulting.com a écrit :
 
 Perhaps an option to direct this output to a file?
 
 On Sat, Aug 8, 2015 at 6:31 AM, William Blevins wblevins...@gmail.com 
 mailto:wblevins...@gmail.com wrote:
 
 
 On Sat, Aug 8, 2015 at 9:14 AM, Alexandre Feblot alexan...@feblot.fr 
 mailto:alexan...@feblot.fr wrote:
 Hi,
 would have this been available, I indeed would already have used scons 
 --envdump=CXXFLAGS,CFLAGS,ENV.PATH A.o
 
 
 When I thought about the feature, I also thought the case 2 was more useful, 
 thank you for your feedback.  I can do both if we decided that printing the 
 whole environment object is ever useful, but lean code bases make for 
 maintainable code bases :)
  
 --
 Alexandre Feblot
 
 Le 8 août 2015 à 15:04, William Blevins wblevins...@gmail.com 
 mailto:wblevins...@gmail.com a écrit :
 
 I guess I should be a bit more explicit about what I am trying to do.
 
 Example:
 A.cpp
 SConstruct - Program( 'exe', Glob( '*.cpp' ) )
 
 My goal original goal was to be able to print environment objects from the 
 command-line without having to modify code:
 1. As written: [Example: scons --debug=envdump A.o would print the build 
 environment object assigned to A.o ].
 2. Afterthought on usability: [Example: scons --envdump=LIBS A.o would 
 print the variable LIBS from the build environment assigned to A.o].
 2.1 Since environment objects are rather large, maybe printing just a single 
 value from the environment object would be more readable and/or desired on a 
 regular basis.
 
 The supplied patch works for Case 1, but I am having a hard time getting 
 only the targets on the command-line.  Currently, the patch prints the 
 environment for all targets on the command-line, plus all their dependencies 
 (as long as they have build environments) and I am hoping to not print their 
 dependencies.
 
 [Example: scons --debug=envdump A.o would print the environment for target 
 A.o but not A.cpp or /usr/bin/g++ because they don't have a build 
 environment.]
 
 [Example: scons --debug=envdump exe would print the environment for target 
 exe plus A.o because it's in the target list (as a dependency of exe)]
 
 If I can figure out a clean way to get only the targets on the command-line, 
 then that makes the most sense.  The real question is do we want Case 1, 
 Case 2,or both capabilities?
 
 V/R,
 William
 
 
 
 
 
 On Sat, Aug 8, 2015 at 3:42 AM, Roberto De Vecchi 
 roberto.devec...@vi-grade.com mailto:roberto.devec...@vi-grade.com wrote:
 William,
 
 from my experience using varname as a filter to limit the output will not 
 help much in big trees where my cloned env are assigned to vars with the 
 same name.
 
 I would find very useful having the env dump limited to the target node 
 specified on the command line: is this already supported by your proposal?
 
 Roberto
 
 --- Messaggio Originale ---
 Da:  William Blevins wblevins...@gmail.com mailto:wblevins...@gmail.com
 Data:08 Agosto 2015 07:22:12
 Oggetto: [Scons-dev] Patch for potential new debug option
 A:   SCons developer list scons-dev@scons.org mailto:scons-dev@scons.org
 
 Here is a patch for dumping build environments via the command-line.
 
 I couldn't ever figure out a good way to get only explicitly lister targets 
 (non-default commandline targets).  It will essentially print the 
 node.get_env().Dump() for all targets with a build_env defined.
 
 I could potentially change it from --debug=envdump to something like 
 --envdump=VARIABLE so that it could print a particular variable rather 
 than the whole env.
 
 Does this interest anyone or waste of chars?
 
 diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
 --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
 +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
 @@ -391,6 +391,21 @@
  def prepare(self):
  pass
  
 +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
 +SCons task for --debug=envdump.  Prints env dump for 
 BUILD_TARGETS.
 +def prepare(self):
 +pass
 +
 +def execute(self):
 +for target in self.targets:
 +if target.get_build_env():
 +print 'Environment dump for target: ' + str(target)
 +print target.get_env().Dump()
 +
 +def executed(self):
 +pass
 +
 +
  class QuestionTask(SCons.Taskmaster.AlwaysTask):
  An SCons task for the -q (question) option.
  def prepare(self):
 @@ -657,6 +672,7 @@
  if memory in debug_values:
  memory_stats.enable(sys.stdout)
  print_objects = (objects in debug_values)
 +options.debug_envdump = ( envdump in debug_values )
  if print_objects:
  SCons.Debug.track_instances = True
  if presub in debug_values:
 @@ -1210,8 +1226,13 @@
  failure_message = done building targets (errors occurred during 
 build).
  else

Re: [Scons-dev] Patch for potential new debug option

[Alexandre Feblot]

Yes, that’s what I meant. I wouldn't feel the need for a specific option when I 
can just do
scons --envdump=xx  file.txt

--
Alexandre Feblot

 Le 8 août 2015 à 19:01, William Blevins wblevins...@gmail.com a écrit :
 
 
 
 On Sat, Aug 8, 2015 at 11:38 AM, Bill Deegan b...@baddogconsulting.com 
 mailto:b...@baddogconsulting.com wrote:
 Perhaps an option to direct this output to a file?
 
 I assume that it can just be piped to a file, but maybe I don't understand 
 your question.
  
 
 On Sat, Aug 8, 2015 at 6:31 AM, William Blevins wblevins...@gmail.com 
 mailto:wblevins...@gmail.com wrote:
 
 
 On Sat, Aug 8, 2015 at 9:14 AM, Alexandre Feblot alexan...@feblot.fr 
 mailto:alexan...@feblot.fr wrote:
 Hi,
 would have this been available, I indeed would already have used scons 
 --envdump=CXXFLAGS,CFLAGS,ENV.PATH A.o
 
 
 When I thought about the feature, I also thought the case 2 was more useful, 
 thank you for your feedback.  I can do both if we decided that printing the 
 whole environment object is ever useful, but lean code bases make for 
 maintainable code bases :)
  
 --
 Alexandre Feblot
 
 Le 8 août 2015 à 15:04, William Blevins wblevins...@gmail.com 
 mailto:wblevins...@gmail.com a écrit :
 
 I guess I should be a bit more explicit about what I am trying to do.
 
 Example:
 A.cpp
 SConstruct - Program( 'exe', Glob( '*.cpp' ) )
 
 My goal original goal was to be able to print environment objects from the 
 command-line without having to modify code:
 1. As written: [Example: scons --debug=envdump A.o would print the build 
 environment object assigned to A.o ].
 2. Afterthought on usability: [Example: scons --envdump=LIBS A.o would 
 print the variable LIBS from the build environment assigned to A.o].
 2.1 Since environment objects are rather large, maybe printing just a single 
 value from the environment object would be more readable and/or desired on a 
 regular basis.
 
 The supplied patch works for Case 1, but I am having a hard time getting 
 only the targets on the command-line.  Currently, the patch prints the 
 environment for all targets on the command-line, plus all their dependencies 
 (as long as they have build environments) and I am hoping to not print their 
 dependencies.
 
 [Example: scons --debug=envdump A.o would print the environment for target 
 A.o but not A.cpp or /usr/bin/g++ because they don't have a build 
 environment.]
 
 [Example: scons --debug=envdump exe would print the environment for target 
 exe plus A.o because it's in the target list (as a dependency of exe)]
 
 If I can figure out a clean way to get only the targets on the command-line, 
 then that makes the most sense.  The real question is do we want Case 1, 
 Case 2,or both capabilities?
 
 V/R,
 William
 
 
 
 
 
 On Sat, Aug 8, 2015 at 3:42 AM, Roberto De Vecchi 
 roberto.devec...@vi-grade.com mailto:roberto.devec...@vi-grade.com wrote:
 William,
 
 from my experience using varname as a filter to limit the output will not 
 help much in big trees where my cloned env are assigned to vars with the 
 same name.
 
 I would find very useful having the env dump limited to the target node 
 specified on the command line: is this already supported by your proposal?
 
 Roberto 
 
 --- Messaggio Originale ---
 Da:  William Blevins wblevins...@gmail.com mailto:wblevins...@gmail.com
 Data:08 Agosto 2015 07:22:12
 Oggetto: [Scons-dev] Patch for potential new debug option
 A:   SCons developer list scons-dev@scons.org mailto:scons-dev@scons.org
 
 Here is a patch for dumping build environments via the command-line.
 
 I couldn't ever figure out a good way to get only explicitly lister targets 
 (non-default commandline targets).  It will essentially print the 
 node.get_env().Dump() for all targets with a build_env defined.
 
 I could potentially change it from --debug=envdump to something like 
 --envdump=VARIABLE so that it could print a particular variable rather 
 than the whole env.
 
 Does this interest anyone or waste of chars?
 
 diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
 --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
 +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
 @@ -391,6 +391,21 @@
  def prepare(self):
  pass
  
 +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
 +SCons task for --debug=envdump.  Prints env dump for 
 BUILD_TARGETS.
 +def prepare(self):
 +pass
 +
 +def execute(self):
 +for target in self.targets:
 +if target.get_build_env():
 +print 'Environment dump for target: ' + str(target)
 +print target.get_env().Dump()
 +
 +def executed(self):
 +pass
 +
 +
  class QuestionTask(SCons.Taskmaster.AlwaysTask):
  An SCons task for the -q (question) option.
  def prepare(self):
 @@ -657,6 +672,7 @@
  if memory in debug_values:
  memory_stats.enable(sys.stdout)
  print_objects = (objects in debug_values

Re: [Scons-dev] Breaking changes in v2.4

[Alexandre Feblot]

Hi,
Old attributes will still be supported, so that the upgrade should be 
transparent. 

--
Alexandre Féblot
(envoyé depuis mon iPhone)

 Le 1 août 2015 à 15:31, Jonathon Reinhart jonathon.reinh...@gmail.com a 
 écrit :
 
 Hello all,
 
 I'm looking at the upcoming Node API changes (for __slots__) mentioned here:
 
 https://pairlist4.pair.net/pipermail/scons-users/2014-July/002734.html
 
 Is it correct that we will be unable to use t.abspath in v2.4, and will 
 instead need to use a new method, t.get_abspath()? Is there any reason the 
 previous attribute name couldn't instead be implemented with @property, so it 
 doesn't break any existing code?
 
 There are a few places where our builds use .abspath because there seemed to 
 be no better way. I have no problem porting the code to work with 2.4 but I'm 
 wondering how many others there are.
 
 Jonathon
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Time for a release?

[Alexandre Feblot]

Hello,

As I expected this 2.3.5 to be released (this was 3 weeks ago), I didn’t yet 
add my latest merged pull requests to the patched 2.3.4 version we are 
currently using in our build farm, but this seems to have stalled.
Dirk, what are your plans, should I wait or rather keep patching our 2.3.4 in 
the meantime?

Thanks

--
Alexandre

 Le 26 mai 2015 à 12:59, anatoly techtonik techto...@gmail.com a écrit :
 
 On Mon, May 25, 2015 at 2:04 AM, Bill Deegan b...@baddogconsulting.com 
 wrote:
 Thanks Gary!
 
 Yay! +1 =)

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] How to traverse the graph after files are read

[Alexandre Feblot]

I did such kind of traversal once: http://pastebin.com/KyEg5ngS
Maybe that was even based on something found in the wiki.

2015-05-20 17:43 GMT+02:00 Gary Oberbrunner ga...@oberbrunner.com:


 On Wed, May 20, 2015 at 11:25 AM, anatoly techtonik techto...@gmail.com
 wrote:

 I want to get target Node based on name passed from command line.
 How to do that?


 node = File(name)

 How to get list of all targets to be built?  User guide:
 http://www.scons.org/doc/HTML/scons-user/ch10s03.html#idp3074280

 the BUILD_TARGETS variable contains a list of the command-line targets,
 if any were specified, and if no command-line targets were specified, it
 contains a list of the targets specified via the Default method or
 function


 Note that it contains a list of Nodes, so you don't need to do anything,
 just iterate over it.

 --
 Gary

 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev


___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Tutorial for Linux versioned libraries

[Alexandre Feblot]

env = Environment()
env.SharedLibrary('SharedVersionedLib', 'file.c', SHLIBVERSION = '1.2.3')
env.SharedLibrary('OtherSharedVersionedLib', 'file.c', SHLIBVERSION =
'2.3.4')

creates

libOtherSharedVersionedLib.so - libOtherSharedVersionedLib.so.2*
libOtherSharedVersionedLib.so.2 - libOtherSharedVersionedLib.so.2.3.4*
libOtherSharedVersionedLib.so.2.3.4*
libSharedVersionedLib.so - libSharedVersionedLib.so.1*
libSharedVersionedLib.so.1 - libSharedVersionedLib.so.1.2.3*
libSharedVersionedLib.so.1.2.3*


2015-05-19 14:49 GMT+02:00 anatoly techtonik techto...@gmail.com:

 On Tue, May 19, 2015 at 12:32 AM, Alexandre Feblot alexan...@feblot.fr
 wrote:
  Hi,
 
  Anatoly, I may not understand what you’re after (and especially your 5
  questions), but I build and install versioned shared libraries
 successfully
  with SCons 2.3.4 on Linux (and since 2.3.2, I think).
  This PR (merged for 2.3.5 or 2.4) lets me use it properly too on Solaris:
 
 https://bitbucket.org/scons/scons/pull-request/186/attempt-to-fix-versionned-shared-library/diff

 From that file there is an example:

 EnsureSConsVersion(2, 3, 3)
 env = Environment()
 env['SHLIBVERSION'] = '1.2.3'
 env.SharedLibrary('SharedVersionedLib', 'file.c')

 In RHVoice I have to build two versioned libs with different
 numbers. How to setup that SHLIBVERSION for them?
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Tutorial for Linux versioned libraries

[Alexandre Feblot]

Hi,Anatoly, I may not understand what you’re after (and especially your 5 questions), but I build and install versioned shared libraries successfully with SCons 2.3.4 on Linux (and since 2.3.2, I think).This PR (merged for 2.3.5 or 2.4) lets me use it properly too on Solaris:https://bitbucket.org/scons/scons/pull-request/186/attempt-to-fix-versionned-shared-library/diffThere is a similar pending PR for AIX from Michael Haubenwallner :https://bitbucket.org/scons/scons/pull-request/144/emulate-svr4-linux-like-soname-on-aix/diffMaybe some other unix-like OS also need the same kind of fix, I don’t know.Installing a versioned shared lib works fine as well, but has a buggy side effect which I didn’t report when I discovered it because I had more important issues to fix:if you install a shared lib in project_root/a/b/c/d/dest/, that will also create the empty dir sharedLib_src_dir/a/b/c/d/dest/I attach a small sample which builds such a versioned shared lib and also shows the install issue.


bugSconsInstallSharedLib.tgz
Description: Binary data
Le 18 mai 2015 à 13:49, anatoly techtonik techto...@gmail.com a écrit :On Fri, May 15, 2015 at 5:58 PM, Bill Deegan b...@baddogconsulting.com wrote:Anatoly,This message would have been better sent to the users mailing list.Not really. Here the recent thread in this list that says that mentionshttp://scons.tigris.org/issues/show_bug.cgi?id=2869 and says that it isnowhere near fixed.https://www.mail-archive.com/scons-dev@scons.org/msg02303.htmlSo, the questions are:1. What is the matter with shared libraries in layman terms?2. What is the system logic to handle them?3. What is the compiler toolchain logic to produce them?4. What is the currently implemented SCons logic?5. Why it is wrong?This is important to be able to fix this stuff. But also important for meto fix this RHVoice issue.I'm taking a look at it now.I'm fairly certain this issue is handled (at least in default branch and2.3.4).If it is fixed in 2.3.4 then http://scons.tigris.org/issues/show_bug.cgi?id=2869should mention what exactly was fixed and where it is documented, becausethe comment says that it was fixed in 2.2.0 and the was about recentversion as I see it.The main SConstruct set's the soname and doesn't use the SCons logic to dothe shared library versioning:Right. And I unable to understand what should be the idea behind.src/SConstruct (line 165) if sys.platform.startswith("linux"):env.Append(SHLINKFLAGS="-Wl,-soname,${TARGET.file}.${libversion.split('.')[0]}")If I comment out those lines (taking shared library versioning out of thepicture) I get the following error:python src/nvda-synthDriver/RHVoice.py -o say.wav "say something"RHVoice 0.5.1RHVoice_tts_engine_struct: No language resources are availableTraceback (most recent call last): File "src/nvda-synthDriver/RHVoice.py", line 285, in module main() File "src/nvda-synthDriver/RHVoice.py", line 235, in main raise RuntimeError("RHVoice: engine initialization error")RuntimeError: RHVoice: engine initialization error"RHVoice 0.5.1" string means the .so is loaded ok.I've sent a pull request with the changes:https://github.com/techtonik/RHVoice/pull/1Thanks. I need to understand the issue better before merging it.1. If RHVoice needs those version numbers at all?2. Why it tries to load so.0 when there is .0.0.0?___Scons-dev mailing listScons-dev@scons.orghttps://pairlist2.pair.net/mailman/listinfo/scons-dev___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Packaging logic?

[Alexandre Feblot]

Oh, ok. 
Thanks for the explanation. 
Forget my previous comment, then :-)

--
Alexandre

 Le 3 avr. 2015 à 18:28, Kenny, Jason L jason.l.ke...@intel.com a écrit :
 
 The current way is to get a source dist and install it.
 This would not stop. You would be able to do the same thing.
  
 The difference in the below would be:
  
 Pip install scons
  
 would be default go to the internet and get SCons
  
 pip install .
  
 would install the current setup.py in the directory ( and I should add allow 
 you to then do a “pip uninstall scons” to remove it. You can still do a 
 “python setup.py install” as well you however would now have meta generated 
 to remove it with a nice command.
  
 Honestly the current model would work as is, making it work with pip just 
 means we have more functional options to provide.
  
 Jason
  
  
 From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Alexandre 
 Feblot
 Sent: Friday, April 3, 2015 4:45 AM
 To: SCons developer list
 Subject: Re: [Scons-dev] Packaging logic?
  
 Hi,
 On environments where  there is no internet access (banks, army, ...), or if 
 scons needs to be internally patched before being installed, the current way 
 is much easier than using pip, I guess. 
 
 --
 Alexandre
 
 Le 2 avr. 2015 à 22:33, Bill Deegan b...@baddogconsulting.com a écrit :
 
 Anatoly,
  
 On non-windows platforms the current recommendation is download the .tgz, 
 unpack, python setup.py it.
  
 That is certainly more complicated than:
  
 pip install scons.
  
  
 -Bill
  
 On Thu, Apr 2, 2015 at 5:43 AM, anatoly techtonik techto...@gmail.com wrote:
 On Wed, Apr 1, 2015 at 6:22 PM, Bill Deegan b...@baddogconsulting.com wrote:
 Jason,
 
 I'm in agreement.
 I think it would be great if the primary way for users to install SCons was 
 via pip (and virtualenv if they like, which I do).
  
 This is a can of worms IMO. SCons is not tool for Python programmers, so if 
 you do that, you will require people to learn about Python packaging, which 
 is an unnecessary hell. If the tools is needed by Python programmers, then 
 plz. state how exactly.
 
 Put the real world need first - what are you trying to achieve with that, 
 excluding the consistency with Python world?
 
 The primary function and the way of using SCons for me (and my vision for 
 everybody else) is to be a build tool that can be put into source repository, 
 so that you can directly build after checkout without messing with 
 apt-get/yum/pip install ... and friends.
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev
 
  
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Announcement: Core changes for v2.4 ahead, Switching the Node class to using slots...

[Alexandre Feblot]

Hi Dirk,

So, I'm glad to say, I built without issue with your switch_to_slots
branch, so many thanks for this again.
While I was at it, I compared the memory usage on a full clean build (-j 8)
The flat period at the end is a post compilation step to create our
distribution, and the last brutal increase is probably caused by the
.sconsign.dblite creation.

Alexandre


2015-03-28 20:28 GMT+01:00 alexan...@feblot.fr:

 Hi Dirk,

 That’s great news. I’ll try that asap next week.

 Thanks a lot!

 Alexandre

  Le 28 mars 2015 à 20:15, Dirk Bächle tshor...@gmx.de a écrit :
 
  Hi Alexandre,
 
  On 02.03.2015 09:06, alexandre.feb...@gmail.com wrote:
  Hi Dirk,
 
  About those new interfaces for accessing node attributes that may get
 initialized lazily, do I understand here the consequences properly?
 
  - Using directly a_node.path or a_node.abspath *must* be replaced in
 all SConstructs/SConscripts by the new interfaces if we wan’t them to keep
 working properly
  - This lets us with 2 solutions:
 1- Do these changes in all our product maintenance branches, and
 even each time we need to checkout again an old tag we want to compile
 again.
 2- Keep an old Scons 2.3 to build our old code, and change our build
 infrastructure to be able to have different SCons paths, so we can chose
 the proper one.
 
 
  as you suggested, I implemented a simple backward compatibility layer
 using the __getattr__ method. It's checked in to the same development
 branch switch_to_slots now. I also measured the speed of the new revision
 against the previous approach, and couldn't find any major impact.
 
  It would be very helpful if you could try and run this latest version
 against your production code. Please give us some feedback about whether
 this would work for you, and allows a flawless transition to the new
 version v2.4.
 
  Best regards,
 
  Dirk
 
  ___
  Scons-dev mailing list
  Scons-dev@scons.org
  https://pairlist2.pair.net/mailman/listinfo/scons-dev


___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Announcement: Core changes for v2.4 ahead, Switching the Node class to using slots...

[Alexandre Feblot]

Hi Dirk,
No problem, thanks for the notice, and glad to know :-)
Either this way or another, I hope you'll be able to stay backward
compatible.

Kind Regards

Alexandre


2015-03-10 9:04 GMT+01:00 Dirk Bächle tshor...@gmx.de:


 Side note @Alexandre: I 'm sorry for not having been able to get back to
 your proposal with getattr. My plan is to profile an experimental version
 within the next few days or so (I'm pretty swamped with work at the moment).
 So, you're not forgotten...I just didn't find the time, yet.


 Best regards,

 Dirk

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Announcement: Core changes for v2.4 ahead, Switching the Node class to using slots...

[alexandre . feblot]

Hi Dirk,

About those new interfaces for accessing node attributes that may get 
initialized lazily, do I understand here the consequences properly?

- Using directly a_node.path or a_node.abspath *must* be replaced in all 
SConstructs/SConscripts by the new interfaces if we wan’t them to keep working 
properly
- This lets us with 2 solutions:
   1- Do these changes in all our product maintenance branches, and even each 
time we need to checkout again an old tag we want to compile again.
   2- Keep an old Scons 2.3 to build our old code, and change our build 
infrastructure to be able to have different SCons paths, so we can chose the 
proper one.



Kind Regards


 Le 28 févr. 2015 à 13:03, Dirk Bächle tshor...@gmx.de a écrit :
 
 Appendix: Short list of changes to the Node* classes
 
 
 - Introduction of decorators for memoizer debugging/counting (we can't
 use metaclasses anymore).
 - Adding interface for accessing node attributes that may get
 initialized lazily:
 t.abspath - t.get_abspath()
 t.labspath - t.get_labspath()
 t.tpath - t.get_tpath()
 t.path_elements - t.get_path_elements()
 t.path - t.get_internal_path()
 
 - Methods like t.exists(), t.rexists() and t.get_contents() can't be
 re-assigned directly anymore. They'll be realized via function maps
 internally ( {int : func} ).
 
 - NodeInfo and BuildInfo will also get switched to __slots__, and get a
 new internal version number (1.0 - 2.0). This means that after the
 switch *all* targets are regarded to be out-of-date on the first build.

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] What to replace the wiki with?

[alexandre . feblot]

Hi,
Just a side remark, as a former user of that wiki:
The issue is that most of it is outdated: refers to obsolete methods, uses 
Python methods whereas there is now a SCons method, etc...
And even when it's not, readers don't trust fully what they see, because, well, 
how can they know if this is still up to date or not?
And this is caused by the very use of a wiki to hold/update the data.

Whereas if all of this could be integrated in the **official** doc, and as 
such, be maintained/updated to follow SCons evolution, it would bring much more 
value to it.


Le 13 déc. 2014 à 17:37, Dirk Bächle tshor...@gmx.de a écrit :

 Gary,
 
 On 13.12.2014 15:06, Gary Oberbrunner wrote:
 Here's a wiki progress report.
 
 * I've re-enabled the regular wiki, in read-only mode. That way at least 
 people can see it.  Pair may take it down again but it's better than nothing.
 * I put up test versions of the wiki, converted to markdown, on both 
 bitbucket and github.
  - bitbucket: https://bitbucket.org/scons/scons/wiki/FrontPage (this is 
 backed by an hg repo)
  - github: https://github.com/garyo/scons-wiki/wiki/FrontPage (this is 
 backed by a git repo)
 
 IMHO, the bitbucket version looks better.  They both are functional.  They 
 both have online editors, and both allow specifying a list of approved 
 contributors who can edit directly, without making pull requests.  They are 
 both DVCS-backed and can accept pull requests (I think, haven't tried that.) 
  I don't know much yet about searchability or TOCs.
 
 Feel free to play with them (but don't expect your changes to persist 
 forever, these are just tests).  Please let me know what you find.
 
 this is awesome! For me, both of the options look good enough to give them a 
 go. The bitbucket version is my winner, because it uses the full page width 
 for content. I think this is important, e.g. for places where we quote source 
 passages with longer lines...
 
 One other thing I noticed is, that on the SconsIsNotSlow page the attached 
 files were successfully converted...but the images seem to be missing. Maybe 
 there is a convert option for that?
 Otherwise, as I said above, it's perfectly good to start from here and 
 manually improve pages where required.
 
 Dirk
 
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] What to replace the wiki with?

[alexandre . feblot]

I knew this was coming while writing it :-)
But no, I must confess I'm not able to spend the time it deserves on this.

Le 13 déc. 2014 à 18:21, Dirk Bächle tshor...@gmx.de a écrit :

 On 13.12.2014 18:00, alexandre.feb...@gmail.com wrote:
 Hi,
 Just a side remark, as a former user of that wiki:
 The issue is that most of it is outdated: refers to obsolete methods, uses 
 Python methods whereas there is now a SCons method, etc...
 And even when it's not, readers don't trust fully what they see, because, 
 well, how can they know if this is still up to date or not?
 And this is caused by the very use of a wiki to hold/update the data.
 
 Whereas if all of this could be integrated in the **official** doc, and as 
 such, be maintained/updated to follow SCons evolution, it would bring much 
 more value to it.
 Maintained and updated by *whom*? Do you volunteer? ;)
 
 The intention of our Wiki is not to provide official documentation, but to 
 collect additional material (sources/docs)...that might once get integrated 
 into the core. But it's mainly there for the community (all users), and it's 
 in the state the community left it in. At least that's the way I see it.
 
 Dirk
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Contribution to SCons development.

[alexandre . feblot]

I found one here: 
http://computer-programming-forum.com/56-python/46da865fb41a1dc3.htm

Ansible worked on that as well: 
https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py
(_symbolic_mode_to_octal, _apply_operation_to_mode, 
_get_octal_mode_from_symbolic_perms)


Le 6 déc. 2014 à 16:24, Gary Oberbrunner ga...@oberbrunner.com a écrit :

 
 
 On Sat, Dec 6, 2014 at 9:37 AM, Shreedhar Manek shreedharma...@gmail.com 
 wrote:
 256 is octal 0400, so it looks like it's only getting the S_IRUSR part.  And 
 that's because I steered you wrong; these are bitmasks, so you have to use 
 bitwise OR:  S_IRUSR | S_IRGRP | S_IROTH
 
 This was it. Thanks!
 
 Should I replace all integers with their counterpart string? Or only select 
 ones?
 
 Well, first, don't forget your real goal is to allow SCons users to actually 
 use a string to set the mode bits.  These constants you're using are in the 
 'stat' module (so 'import stat' will fix your bug below), but they are still 
 numeric absolute constants.
 
 I think the original issue 
 (http://scons.tigris.org/issues/show_bug.cgi?id=2494) asks for allowing users 
 to use actual strings like the chmod command-line utility, which allows 
 relative modes like ug+rw,o-rwx as well as numeric absolute modes like 
 777 (that's still a string, note). (see the chmod man page, for instance 
 http://linux.die.net/man/1/chmod.)  SCons users could already just do 'import 
 stat' and use the named constants, but those are absolute; the desired chmod 
 modes are relative to the current state.  The main task for this issue is, I 
 think, to parse those relative modes (relative to the file's current state) 
 and compute the desired final mode.
 
 If you can write a function parse_mode_string(mode_string, 
 original_mode_bits), that's 90% of the work.  (Actually I'm surprised there 
 isn't one already written out there somewhere.)
 
 -- Gary
 
 
 Replacing the first 0777 with S_IRWXU | S_IRWXG | S_IRWXO in 
 
 test.write('SConstruct', 
 Execute(Chmod('f1', 0666))
 Execute(Chmod(('f1-File'), 0666))
 Execute(Chmod('d2', S_IRWXU | S_IRWXG | S_IRWXO))
 Execute(Chmod(Dir('d2-Dir'), 0777))
 def cat(env, source, target):
 target = str(target[0])
 f = open(target, wb)
 for src in source:
 f.write(open(str(src), rb).read())
 f.close()
 Cat = Action(cat)
 env = Environment()
 env.Command('bar.out', 'bar.in', [Cat,
   Chmod(f3, 0666),
   Chmod(d4, 0777)])
 env = Environment(FILE = 'f5')
 env.Command('f6.out', 'f6.in', [Chmod('$FILE', 0666), Cat])
 env.Command('f7.out', 'f7.in', [Cat,
 Chmod('Chmod-$SOURCE', 0666),
 Chmod('${TARGET}-Chmod', 0666)])
 
 # Make sure Chmod works with a list of arguments
 env = Environment(FILE = 'f9')
 env.Command('f8.out', 'f8.in', [Chmod(['$FILE', File('f10')], 0666), Cat])
 Execute(Chmod(['d11', Dir('d12')], 0777))
 )
 
 gives the following error,
 
 STDERR 
 =
 NameError: name 'S_IRWXU' is not defined:
   File /tmp/testcmd.23013.se_zJm/SConstruct, line 4:
 Execute(Chmod('d2', S_IRWXU | S_IRWXG | S_IRWXO))
 
 FAILED test of /home/shrox/scons/src/script/scons.py
   at line 598 of /home/shrox/scons/QMTest/TestCommon.py (_complete)
   from line 701 of /home/shrox/scons/QMTest/TestCommon.py (run)
   from line 390 of /home/shrox/scons/QMTest/TestSCons.py (run)
   from line 123 of test/Chmod.py
 
 
 
 -- 
 Shreedhar Manek
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev
 
 
 
 
 -- 
 Gary
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Using SHLIBVERSION fails on Solaris and probably all other unixes but Linux

[alexandre . feblot]

Pull request created: 
https://bitbucket.org/scons/scons/pull-request/186/attempt-to-fix-versionned-shared-library


Le 19 sept. 2014 à 22:54, alexandre.feb...@gmail.com a écrit :

 I may, but I'm pretty sure my patch is OK for me but only for me, and I've no 
 real clue on what is the correct way to fix this in all situations.
 
 Le 19 sept. 2014 à 21:48, William Blevins wblevins...@gmail.com a écrit :
 
 Would you mind making a pull request via Bitbucket?
 
 On Sep 19, 2014 1:03 PM, Alexandre Feblot alexan...@feblot.fr wrote:
 The change on SCons/Tool/__init__.py line 308 was a bad idea, it broke 
 Solaris build.
 Attached is my final patch which seem to work properly.
 
 2014-09-19 17:36 GMT+02:00 Alexandre Feblot alexan...@feblot.fr:
 So, I fixed point 2 by adding the same kind of fixes ( or platform == 
 'sunos') on :
 
 * required for sure:
 SCons/Tool/__init__.py line 259
 
 SCons/Tool/__init__.py line 308
 
 
 * not required but seems related, I don't really know:
 SCons/Tool/install.py line 152
 
 SCons/Tool/install.py line 163
 
 
 2014-09-19 15:30 GMT+02:00 Alexandre Feblot alexan...@feblot.fr:
 Hi,
 
 as the title says, it fails with the following error: IndexError: list 
 index out of range in SCons/Tool/link.py.
 
 The reason is that versionned shared lib seem to be handled properly for 
 unixes if PLATFORM=='posix', whereas on Solaris, it is detected assunos 
 rather than posix.
 
 
 I tried to fix at SCons/Tool/link.py line 108: if platform == 'posix' or 
 platform == 'sunos':, but
 This is an ugly fix which does not take into account other unixes which 
 probably fail the same way. In fact, 'posix' is not at the same meaning 
 level as 'sunos'. Shouldn't PLATFORM be set to something like 'linux' on 
 linux, and a posix flag to be set for all posix platforms?
 This just fixes part of the issue. It now does create the lib with its 
 version number, but not the 2 symlinks (and I don't really kow where to 
 search for that. Any hint will be welcome).
 
 Note: I'd be happy to fill a bug, but should this still be done on Tigris, 
 with ongoing migrations to new bug trackers (and I'm totally lost with the 
 current status of these migrations)?
 
 Attached: the smallest example to reproduce the issue.
 
 
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev
 

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Using SHLIBVERSION fails on Solaris and probably all other unixes but Linux

[Alexandre Feblot]

Hi,

as the title says, it fails with the following error: IndexError: list
index out of range in SCons/Tool/link.py.

The reason is that versionned shared lib seem to be handled properly for
unixes if PLATFORM=='posix', whereas on Solaris, it is detected assunos
rather than posix.


I tried to fix at SCons/Tool/link.py line 108: if platform == 'posix' or
platform == 'sunos':, but

   1. This is an ugly fix which does not take into account other unixes
   which probably fail the same way. In fact, 'posix' is not at the same
   meaning level as 'sunos'. Shouldn't PLATFORM be set to something like
   'linux' on linux, and a posix flag to be set for all posix platforms?
   2. This just fixes part of the issue. It now does create the lib with
   its version number, but not the 2 symlinks (and I don't really kow where to
   search for that. Any hint will be welcome).


Note: I'd be happy to fill a bug, but should this still be done on Tigris,
with ongoing migrations to new bug trackers (and I'm totally lost with the
current status of these migrations)?

Attached: the smallest example to reproduce the issue.


bugSconsSharedLib.tar
Description: Unix tar archive
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Using SHLIBVERSION fails on Solaris and probably all other unixes but Linux

[Alexandre Feblot]

So, I fixed point 2 by adding the same kind of fixes ( or platform ==
'sunos') on :

* required for sure:

SCons/Tool/__init__.py line 259

SCons/Tool/__init__.py line 308

* not required but seems related, I don't really know:

SCons/Tool/install.py line 152

SCons/Tool/install.py line 163

2014-09-19 15:30 GMT+02:00 Alexandre Feblot alexan...@feblot.fr:

 Hi,

 as the title says, it fails with the following error: IndexError: list
 index out of range in SCons/Tool/link.py.

 The reason is that versionned shared lib seem to be handled properly for
 unixes if PLATFORM=='posix', whereas on Solaris, it is detected assunos
 rather than posix.


 I tried to fix at SCons/Tool/link.py line 108: if platform == 'posix' or
 platform == 'sunos':, but

1. This is an ugly fix which does not take into account other unixes
which probably fail the same way. In fact, 'posix' is not at the same
meaning level as 'sunos'. Shouldn't PLATFORM be set to something like
'linux' on linux, and a posix flag to be set for all posix platforms?
2. This just fixes part of the issue. It now does create the lib with
its version number, but not the 2 symlinks (and I don't really kow where to
search for that. Any hint will be welcome).


 Note: I'd be happy to fill a bug, but should this still be done on Tigris,
 with ongoing migrations to new bug trackers (and I'm totally lost with the
 current status of these migrations)?

 Attached: the smallest example to reproduce the issue.

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] JetBrains

[Alexandre Feblot]

Netbeans: yes, creating a project by having it run a SCons build and scan
build commands works quite well.

2014-09-15 13:32 GMT+02:00 Russel Winder rus...@winder.org.uk:

 I see that JetBrains new C/C++ IDE, CLion, assumes you will use CMake.
 This will not be good for SCons use.

 I also note that Netbeans assumes you will use Autotools for C/C++
 projects, but that you can convince it to use SCons by devious means.
 --
 Russel.

 =
 Dr Russel Winder  t: +44 20 7585 2200   voip:
 sip:russel.win...@ekiga.net
 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
 London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev


___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] 2.3.3 Release issue ?

[Alexandre Feblot]

Hi,

Would there be a release issue with 2.3.3 ?

Downloaded from http://prdownloads.sourceforge.net/scons/scons-2.3.3.tar.gz

Installed by python setup.py install --prefix /usr/local --optimize 2
--symlink-scons

scons --version
SCons by Steven Knight et al.:
script: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
engine: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
engine path: ['/usr/local/lib/scons-2.3.3/SCons']
Copyright (c) 2001 - 2014 The SCons Foundation


EnsureSConsVersion() just prints:


*scons: warning: EnsureSConsVersion is ignored for development version*
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] 2.3.3 Release issue ?

[Alexandre Feblot]

Thx for pinpointing the issue location, anyway. I fixed my own in the
meantime.

2014-09-08 19:47 GMT+02:00 anatoly techtonik techto...@gmail.com:

 Anyway we need to wait when Gary is available to wrap a new release
 with this fix. Is there anybody else who can release?

 On Mon, Sep 8, 2014 at 8:27 PM, anatoly techtonik techto...@gmail.com
 wrote:
  I wonder why buildbots are silent about this?
 
  On Mon, Sep 8, 2014 at 8:25 PM, anatoly techtonik techto...@gmail.com
 wrote:
  On Mon, Sep 8, 2014 at 7:41 PM, Alexandre Feblot alexan...@feblot.fr
 wrote:
  Hi,
 
  Would there be a release issue with 2.3.3 ?
 
  Downloaded from
 http://prdownloads.sourceforge.net/scons/scons-2.3.3.tar.gz
 
  Installed by python setup.py install --prefix /usr/local --optimize 2
  --symlink-scons
 
  scons --version
  SCons by Steven Knight et al.:
  script: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
  engine: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
  engine path: ['/usr/local/lib/scons-2.3.3/SCons']
  Copyright (c) 2001 - 2014 The SCons Foundation
 
 
  EnsureSConsVersion() just prints:
 
  scons: warning: EnsureSConsVersion is ignored for development version
 
  Yes. This is a bug:
 
 def EnsureSConsVersion(self, major, minor, revision=0):
 Exit abnormally if the SCons version is not late enough.
 if SCons.__version__ == '2.3.3':
 SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning,
 
  This should be:
 
 def EnsureSConsVersion(self, major, minor, revision=0):
 Exit abnormally if the SCons version is not late enough.
 if SCons.__version__ == '__VERSION__':
 SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning,
 
  The __VERSION__ of course was replaced during our build process. The
  quick fix is:
  -   if SCons.__version__ == '__VERSION__':
  +   if SCons.__version__ == '__' + 'VERSION__':
 
 
 
  --
  anatoly t.



 --
 anatoly t.
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Windows Path

[alexandre . feblot]

Le 7 sept. 2014 à 14:53, Russel Winder rus...@winder.org.uk a écrit :

 On Sat, 2014-09-06 at 20:31 +0200, alexandre.feb...@gmail.com wrote:
 Hi,
 
 Creation of a temporary dir containing symlinks to tools which have been 
 found, and adding this dir in the SCons PATH?
 On windows, this can be achieved with junction points (this is pretty much 
 what we do to force using the 64 bit linker during a 32 bit compilation due 
 to the size of our libs/executables in debug mode).
 
 Indeed this works in principle for all platforms not just Windows, OSX
 without MacPorts or HomeBrew for example.
 
 Doesn't windows now have proper symbolic links?
 
 Of course we have to deal with windows back beyond XP?
 
 -- 
 Russel.


Symlinks would work on unix platforms, but regarding Windows... Forget my 
suggestion, sorry:

In fact, symbolic or hard links required administrator rights, so that was a 
no-go.
Junction points didn't, but they only link directories, not files, so what I 
suggested before couldn't  be done and we in fact did something like 
env['LiNK'] = 'tmpdir/JunctionPoint_to_64bit_tools_dir/link' (which is 
exactly what you want to avoid :-)

And we did that in the first place because simply doing env['LINK'] = 
'C:\Program Files\\link' failed due to spaces in the path. But this is 
another story. Now that I think about this again, I don't even know if we tried 
just using quotes or env.File() !

Alexandre
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Strange behavior of env.Execute(python script) on Windows

[Alexandre Feblot]

Hi,
Would any of you have an idea on the behavior of printpath.py in the small
test below? What happens to the PATH? Other variables are transfered
properly. The similar perl test shows the PATH as expected.

Sconstruct:
env = Environment()
env['ENV']['PATH'] += ';C:\\XX'
env.Execute(File('#/printpath.py').abspath)
env.Execute(File('#/printpath.pl').abspath)

printpath.pl:
#!/usr/bin/perl
print $ENV{PATH}\n;

printpath.py:
#!/usr/bin/python
import os
print os.environ['PATH']

On windows (server 2008R2), with python 2.7.2, the result is:
scons: Reading SConscript files ...
C:\bug\printpath.py
C:\Python27\
C:\bug\printpath.pl
c:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\BIN\amd64;c:\Windows\Microsoft.NET\Framework64\v3.5;c:\Windows\Microsoft.NET\Framework64\v3.5\Microsoft
.NET Framework 3.5 (Pre-Release
Version);c:\Windows\Microsoft.NET\Framework64\v2.0.50727;c:\Program Files
(x86)\Microsoft Visual Studio 9.0\VC\VCPackages;c:\Program Files
(x86)\Microsoft Visual Studio 9.0\Common7\IDE;c:\Program Files
(x86)\Microsoft Visual Studio 9.0\Common7\Tools;c:\Program Files
(x86)\Microsoft Visual Studio 9.0\Common7\Tools\bin;C:\Program
Files\Microsoft SDKs\Windows\v6.0A\bin\x64;C:\Program Files\Microsoft
SDKs\Windows\v6.0A\bin\win64\x64;C:\Program Files\Microsoft
SDKs\Windows\v6.0A\bin;C:\Windows\System32;C:\XX
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.

Thanks
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Strange behavior of env.Execute(python script) on Windows

[Alexandre Feblot]

I'm using Active State ActivePython 2.7.2.5.
I'm going to try the official python, then.
Thanks.


2014-03-05 17:07 GMT+01:00 Gary Oberbrunner ga...@oberbrunner.com:

 Your example works OK for me; this is only the printpath.py part:

 scons: Reading SConscript files ...
 C:\tmp\printpath.py
 C:\Program Files (x86)\Microsoft Visual Studio
 11.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files
 (x86)\Microsoft Visual Studio
 11.0\VC\BIN\amd64;c:\Windows\Microsoft.NET\Framework64\v4.0.30319;c:\Windows\Microsoft.NET\Framework64\v3.5;C:\Program
 Files (x86)\Microsoft Visual Studio 11.0\VC\VCPackages;C:\Program Files
 (x86)\Microsoft Visual Studio 11.0\Common7\IDE;C:\Program Files
 (x86)\Microsoft Visual Studio 11.0\Common7\Tools;C:\Program Files
 (x86)\Microsoft Visual Studio 11.0\Team Tools\Performance
 Tools\x64;C:\Program Files (x86)\Microsoft Visual Studio 11.0\Team
 Tools\Performance Tools;C:\Program Files (x86)\Windows
 Kits\8.0\bin\x64;C:\Program Files (x86)\Windows Kits\8.0\bin\x86;C:\Program
 Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\x64;C:\Program
 Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\x64;C:\Program Files
 (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools;C:\Program Files
 (x86)\Microsoft
 SDKs\Windows\v7.0A\bin\;C:\Windows\System32;C:\XX

 Are you using cygwin python or real python?  I suggest trying real (
 python.org) python if you're using cygwin.  There are some oddities with
 cygwin python.



 On Wed, Mar 5, 2014 at 10:31 AM, Alexandre Feblot alexan...@feblot.frwrote:

 Hi,
 Would any of you have an idea on the behavior of printpath.py in the
 small test below? What happens to the PATH? Other variables are transfered
 properly. The similar perl test shows the PATH as expected.

 Sconstruct:
 env = Environment()
 env['ENV']['PATH'] += ';C:\\XX'
 env.Execute(File('#/printpath.py').abspath)
 env.Execute(File('#/printpath.pl').abspath)

 printpath.pl:
 #!/usr/bin/perl
 print $ENV{PATH}\n;

 printpath.py:
 #!/usr/bin/python
 import os
 print os.environ['PATH']

 On windows (server 2008R2), with python 2.7.2, the result is:
 scons: Reading SConscript files ...
 C:\bug\printpath.py
 C:\Python27\
 C:\bug\printpath.pl
 c:\Program Files (x86)\Microsoft Visual Studio
 9.0\VC\BIN\amd64;c:\Windows\Microsoft.NET\Framework64\v3.5;c:\Windows\Microsoft.NET\Framework64\v3.5\Microsoft
 .NET Framework 3.5 (Pre-Release
 Version);c:\Windows\Microsoft.NET\Framework64\v2.0.50727;c:\Program Files
 (x86)\Microsoft Visual Studio 9.0\VC\VCPackages;c:\Program Files
 (x86)\Microsoft Visual Studio 9.0\Common7\IDE;c:\Program Files
 (x86)\Microsoft Visual Studio 9.0\Common7\Tools;c:\Program Files
 (x86)\Microsoft Visual Studio 9.0\Common7\Tools\bin;C:\Program
 Files\Microsoft SDKs\Windows\v6.0A\bin\x64;C:\Program Files\Microsoft
 SDKs\Windows\v6.0A\bin\win64\x64;C:\Program Files\Microsoft
 SDKs\Windows\v6.0A\bin;C:\Windows\System32;C:\XX
 scons: done reading SConscript files.
 scons: Building targets ...
 scons: `.' is up to date.
 scons: done building targets.

 Thanks


 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev




 --
 Gary

 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev


___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

Re: [Scons-dev] [GSoC Mentors Announce] Now Accepting Applications for Mentoring Organizations for GSoC 2014

[alexandre . feblot]

Hum,
My brain is so used to overlooking ads banners that I did not see the wiki one 
explaining why accounts creation is currently disabled :-)

Le 13 févr. 2014 à 22:39, alexandre.feb...@gmail.com a écrit :

 Hi Gary,
 
 I have have no wiki account yet, and it seems impossible to register right 
 now: 
 http://www.scons.org/wiki/any_page?action=newaccount leads to Unknown action 
 newaccount.
 
 But feel free to add it, next to or instead of 
 http://www.scons.org/wiki/ColorBuildMessages.
 
 
 
 Le 13 févr. 2014 à 22:21, Gary Oberbrunner ga...@oberbrunner.com a écrit :
 
 Hi Alexandre; can you post that on the wiki?  Or at least link to it?
 
 thanks!
 
 
 On Thu, Feb 13, 2014 at 12:22 PM, Alexandre Feblot alexan...@feblot.fr 
 wrote:
 Damned, ugly raw paste.
 Here it is in a better shape: http://pastie.org/8730387
 
 
 
 2014-02-13 18:14 GMT+01:00 Alexandre Feblot alexan...@feblot.fr:
 Not sure exactly about what you fixed, but as you speak about coloring, I 
 wanted to share the colorizer tool I am using. Compared to what was proposed 
 in the wiki, it allows to colorize everything in stdout and/or stderr, being 
 printed either by scons itself or by external commands spawned by scons. In 
 order to do this, indeed, I had to overwrite the spawn method. Works only on 
 unix, I used basic terminal color codes.
 
 import sys
 [...snip...]
 return 1
 
 
 
 2014-02-12 16:25 GMT+01:00 Kenny, Jason L jason.l.ke...@intel.com:
 
  Fix async subprocess execution with proper handling of std* streams.
 
 So I fixed the issue with output in Parts. I not saying it could not be 
 clean up some more. However it solves the output issues, and adds coloring ( 
 which seems to need some fixing in certain cases.. ie mac mostly) and 
 logging support. It might not be too hard for someone to move the code over 
 to SCons and integrated its usage into SCons.
 
  
 
 Just a thought.
 
  
 
 Jason
 
  
 
 From: scons-dev-boun...@scons.org [mailto:scons-dev-boun...@scons.org] On 
 Behalf Of Bill Deegan
 Sent: Tuesday, February 11, 2014 5:58 PM
 To: SCons developer list
 Subject: Re: [Scons-dev] Fwd: [GSoC Mentors Announce] Now Accepting 
 Applications for Mentoring Organizations for GSoC 2014
 
  
 
 Anatoly,
 
 While I agree many of the things in your list would be nice to get done.
 I'm not sure most of them are a good thing for a GSOC student to attempt.
 
 Few students would have the time to ramp up on all the info needed and make 
 some concrete contributions in the time allowed.
 
 my 2cents.
 
 -Bill
 
  
 
 On Tue, Feb 11, 2014 at 12:35 PM, anatoly techtonik techto...@gmail.com 
 wrote:
 
 On Tue, Feb 11, 2014 at 11:30 PM, anatoly techtonik techto...@gmail.com 
 wrote:
  On Mon, Feb 3, 2014 at 10:05 PM, Gary Oberbrunner ga...@oberbrunner.com 
  wrote:
  Hi folks; if we want to get a GSoC project this year, now's the time to
  think about it.
 
  Top of my priority list for a GSoC student would be someone to convert
  everything to python3, finishing what we've started already.
 
  Can of worms. IMHO.
 
  Other ideas?
 
  Concentrate on visualizing and documenting how SCons works. Cleaning
  up and opening internals to the public. Enhance test running, bring
  back slaves. List current workflows and tools discovery, research best
  practices and see how the tool discovery should be improved.
 
  Research and document the problem of compiling C programs.
  Research and document the problem of compiling C++ programs.
  Enhance documentation.
  Add more design touches.
  Integrate best practices from other projects.
 
  Fix async subprocess execution with proper handling of std* streams.
 
 Also integrate with https://github.com/facebook/watchman to speed up
 rebuilds (instead of scanning the whole tree again and again).
 
 --
 anatoly t.
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev
 
  
 
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev
 
 
 
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev
 
 
 
 
 -- 
 Gary
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev
 

___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Fwd: [GSoC Mentors Announce] Now Accepting Applications for Mentoring Organizations for GSoC 2014

[Alexandre Feblot]

Not sure exactly about what you fixed, but as you speak about coloring, I
wanted to share the colorizer tool I am using. Compared to what was
proposed in the wiki, it allows to colorize everything in stdout and/or
stderr, being printed either by scons itself or by external commands
spawned by scons. In order to do this, indeed, I had to overwrite the spawn
method. Works only on unix, I used basic terminal color codes.

import sys
import os
import re
import select
import subprocess
import platform

c_underline =\033[04m
c_blink =\033[05m
c_norm  =\033[00m

# Normal
c_black= \033[30m
c_red  = \033[31m
c_green= \033[32m
c_yellow   = \033[33m
c_blue = \033[34m
c_purple   = \033[35m
c_cyan = \033[36m
c_white= \033[37m

# Bold
cb_black= \033[1;30m
cb_red  = \033[1;31m
cb_green= \033[1;32m
cb_yellow   = \033[1;33m
cb_blue = \033[1;34m
cb_purple   = \033[1;35m
cb_cyan = \033[1;36m
cb_white= \033[1;37m

# BackGround
cback_blue = \033[1;44m
cback_white= \033[1;47m
cback_black= \033[1;45m

#--
# regexps and what they will be replaced with
#--
colorPatterns = [
(re.compile(r'(.*: [Ww]arning[:,].*)'),
r'%s[Warning] %s\1%s' % (cb_red, cb_yellow, c_norm)),
(re.compile(r'(.*: [Ee]rror[:,].*)')  ,
r'%s[Error] \1%s' % (cb_red, c_norm)),
(re.compile(r'\[(CC|CXX|UIC|MOC|Q2K|RCC|RAN|LNK)\](.*?)([^/]+)$') ,
r'%s[\1]%s\2%s\3%s'   % (c_blue, c_purple, cb_purple, c_norm)),
]

#--
# Colorize a line according to defined patterns
#--
def colorize(line):
for regexp, replacement in colorPatterns:
line = regexp.sub(replacement, line)

return line;


#--
# Allows to hijack default stdout and stderr to colorize them
#--
class Colorizer(object):
def __init__(self, redirected):
self.buf = ''
self.redirected = redirected

def isatty(self):
return self.redirected.isatty()

def write(self, msg):
if self.buf:
msg = self.buf + msg
self.buf = ''
line, sep, msg = msg.partition('\n')
while sep:
self.redirected.write(colorize(line)+'\n')
line, sep, msg = msg.partition('\n')
if line:
self.buf = line

def __del__(self):
if self.buf:
self.redirected.write(colorize(self.buf))


#--
# Asynchroneously stream subprocess stdout/stderr to our own stdout/stderr
#--
def colorizeSpawn(shell, escape, cmd, args, env):
proc = subprocess.Popen(' '.join(args),
stderr=subprocess.PIPE, stdout=subprocess.PIPE,
shell=True, env=env
)
monitoredStreams = [proc.stdout, proc.stderr]
while monitoredStreams:
rsig, wsig, xsig = select.select(monitoredStreams, [], [])

if proc.stdout in rsig:
data = os.read(proc.stdout.fileno(), 1024)
if data:
sys.stdout.write(data)
else:
proc.stdout.close()
monitoredStreams.remove(proc.stdout)

if proc.stderr in rsig:
data = os.read(proc.stderr.fileno(), 1024)
if data:
sys.stderr.write(data)
else:
proc.stderr.close()
monitoredStreams.remove(proc.stderr)

ret = proc.poll()
return ret


#--
# Initialize the colorizer
#--
def generate(env, **kw):
if platform.system() != 'Windows':
if type(sys.stdout) == file and sys.stdout.isatty():
env['SPAWN'] = colorizeSpawn
sys.stdout = Colorizer(sys.stdout)
if type(sys.stderr) == file and sys.stderr.isatty():
env['SPAWN'] = colorizeSpawn
sys.stderr = Colorizer(sys.stderr)

def exists(env):
return 1



2014-02-12 16:25 GMT+01:00 Kenny, Jason L jason.l.ke...@intel.com:

   Fix async subprocess execution with proper handling of std* streams.

 So I fixed the issue with output in Parts. I not saying it could not be
 clean up some more. However it solves the output issues, and adds coloring
 ( which seems to need some fixing in certain cases.. ie mac mostly) and
 logging support. It might not be too hard for someone 

Re: [Scons-dev] [GSoC Mentors Announce] Now Accepting Applications for Mentoring Organizations for GSoC 2014

[alexandre . feblot]

Hi Gary,

I have have no wiki account yet, and it seems impossible to register right now: 
http://www.scons.org/wiki/any_page?action=newaccount leads to Unknown action 
newaccount.

But feel free to add it, next to or instead of 
http://www.scons.org/wiki/ColorBuildMessages.



Le 13 févr. 2014 à 22:21, Gary Oberbrunner ga...@oberbrunner.com a écrit :

 Hi Alexandre; can you post that on the wiki?  Or at least link to it?
 
 thanks!
 
 
 On Thu, Feb 13, 2014 at 12:22 PM, Alexandre Feblot alexan...@feblot.fr 
 wrote:
 Damned, ugly raw paste.
 Here it is in a better shape: http://pastie.org/8730387
 
 
 
 2014-02-13 18:14 GMT+01:00 Alexandre Feblot alexan...@feblot.fr:
 Not sure exactly about what you fixed, but as you speak about coloring, I 
 wanted to share the colorizer tool I am using. Compared to what was proposed 
 in the wiki, it allows to colorize everything in stdout and/or stderr, being 
 printed either by scons itself or by external commands spawned by scons. In 
 order to do this, indeed, I had to overwrite the spawn method. Works only on 
 unix, I used basic terminal color codes.
 
 import sys
 [...snip...]
 return 1
 
 
 
 2014-02-12 16:25 GMT+01:00 Kenny, Jason L jason.l.ke...@intel.com:
 
  Fix async subprocess execution with proper handling of std* streams.
 
 So I fixed the issue with output in Parts. I not saying it could not be clean 
 up some more. However it solves the output issues, and adds coloring ( which 
 seems to need some fixing in certain cases.. ie mac mostly) and logging 
 support. It might not be too hard for someone to move the code over to SCons 
 and integrated its usage into SCons.
 
  
 
 Just a thought.
 
  
 
 Jason
 
  
 
 From: scons-dev-boun...@scons.org [mailto:scons-dev-boun...@scons.org] On 
 Behalf Of Bill Deegan
 Sent: Tuesday, February 11, 2014 5:58 PM
 To: SCons developer list
 Subject: Re: [Scons-dev] Fwd: [GSoC Mentors Announce] Now Accepting 
 Applications for Mentoring Organizations for GSoC 2014
 
  
 
 Anatoly,
 
 While I agree many of the things in your list would be nice to get done.
 I'm not sure most of them are a good thing for a GSOC student to attempt.
 
 Few students would have the time to ramp up on all the info needed and make 
 some concrete contributions in the time allowed.
 
 my 2cents.
 
 -Bill
 
  
 
 On Tue, Feb 11, 2014 at 12:35 PM, anatoly techtonik techto...@gmail.com 
 wrote:
 
 On Tue, Feb 11, 2014 at 11:30 PM, anatoly techtonik techto...@gmail.com 
 wrote:
  On Mon, Feb 3, 2014 at 10:05 PM, Gary Oberbrunner ga...@oberbrunner.com 
  wrote:
  Hi folks; if we want to get a GSoC project this year, now's the time to
  think about it.
 
  Top of my priority list for a GSoC student would be someone to convert
  everything to python3, finishing what we've started already.
 
  Can of worms. IMHO.
 
  Other ideas?
 
  Concentrate on visualizing and documenting how SCons works. Cleaning
  up and opening internals to the public. Enhance test running, bring
  back slaves. List current workflows and tools discovery, research best
  practices and see how the tool discovery should be improved.
 
  Research and document the problem of compiling C programs.
  Research and document the problem of compiling C++ programs.
  Enhance documentation.
  Add more design touches.
  Integrate best practices from other projects.
 
  Fix async subprocess execution with proper handling of std* streams.
 
 Also integrate with https://github.com/facebook/watchman to speed up
 rebuilds (instead of scanning the whole tree again and again).
 
 --
 anatoly t.
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev
 
  
 
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev
 
 
 
 
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev
 
 
 
 
 -- 
 Gary
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

Re: [Scons-dev] [scons-dev] fix for 2903 breaks LIBPATH.py test..

[alexandre . feblot]

Yes,
that was my initial conclusion. This commit changed:

ShLibAction = SCons.Defaults.ShLinkAction(target, source, envlink)
to:

def VersionedSharedLibrary(target = None, source= None, env=None):
...
result = SCons.Defaults.ShLinkAction(target, source, envlink)
...
return result
ShLibAction = SCons.Action.Action(VersionedSharedLibrary, None)

--
SCons.Defaults.ShLinkAction is a string action, the string being SHLINKCOM, and 
this is why I re-added it with:
ShLibAction = SCons.Action.Action(VersionedSharedLibrary, None, 
varlist=['SHLINKCOM'])

So, except strange side effects that I could not imagine because I'm a real 
Scons code newbie, I would have thought that the final behavior is the same 
than the one before the versionned libraries addition.

___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

Re: [Scons-dev] scons rpath vs signature

[Alexandre Feblot]

Strange. Wasn't this also happening before scons 2.3 ? Or had this test
been introdcued with scons 2.3 ?


2013/10/2 Gary Oberbrunner ga...@oberbrunner.com

 On Wed, Oct 2, 2013 at 8:17 AM, Alexandre Feblot alexan...@feblot.frwrote:

 if you're speaking of scons 2.3.0, I think it looks like an effect of
 http://scons.tigris.org/issues/show_bug.cgi?id=2903
 which will be fixed in the next release.


 Yes... however the fix for that bug will perhaps be a bit more involved.
 It now causes an unnecessary rebuild even when LIBPATH changes but the
 actual libs found did not change.  (That's the new test failure recently
 reported here.)

 --
 Gary

 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev


___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

Re: [Scons-dev] getting changes accepted

[alexandre . feblot]

I used the test case described in the bug, but I have nothing to integrate in 
scons test suite.

Le 26 sept. 2013 à 14:16, Gary Oberbrunner ga...@oberbrunner.com a écrit :

 
 On Thu, Sep 26, 2013 at 8:11 AM, alexandre.feb...@gmail.com wrote:
 Hi,
 By the way, did you review mine? ( 
 https://bitbucket.org/scons/scons/pull-request/86/fix-http-sconstigrisorg-issues/diff
  )
 
 I saw it, Alexandre -- it's definitely in the queue, and on simple inspection 
 it looks OK.  I just want to make sure that that's the best way to fix it.  
 Do you have a test case for it? 
 
 -- 
 Gary
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 http://two.pairlist.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev