Re: [Scons-dev] [Scons-users] SCons 4.0.0 Released

[Gary Oberbrunner]

Congratulations! SCons 4.0!!!

On Sat, Jul 4, 2020 at 6:57 PM Bill Deegan 
wrote:

>   A new SCons release, 4.0.0, is now available
>   on the SCons download page:
>
>   https://scons.org/pages/download.html
>
>   Here is a summary of the changes since 3.1.2:
>
>   NEW FUNCTIONALITY
>
> - Added support for scanning multiple entries in an action string if
>   IMPLICIT_COMMAND_DEPENDENCIES is set to 2 or 'all'. This enables
> more thorough
>   action scanning where every item in each command line is scanned to
> determine
>   if it is a non-source and non-target path and added to the list of
> implicit dependencies
>   for the target.
> - Added new module SCons.Scanner.Python to allow scanning .py files.
> - Added support for explicitly passing a name when creating Value()
> nodes. This may be useful
>   when the value can't be converted to a string or if having a name is
> otherwise desirable.
> - Added a new flag called "linedraw" for the command line argument
>  "--tree"
>   that instructs scons to use single line drawing characters to draw
> the dependency tree.
> - Add CompilationDatabase() builder in compilation_db tool.
> Contributed by MongoDB.
>   Setting COMPILATIONDB_USE_ABSPATH to True|False controls whether the
> files are absolute or relative
>   paths.  Address Issue #3693 and #3694 found during development.
> - Extended `Environment.Dump()` to select a format to serialize
> construction variables (pretty, json).
> - New conditional C Scanner (`SCons.Scanner.C.CConditionalScanner()`)
>   which interprets C/C Preprocessor conditional syntax (#ifdef, #if,
> #else,
>   #elif, #define, etc.)
> - Experimental New Feature: Enable caching MSVC configuration
>   If SCONS_CACHE_MSVC_CONFIG shell environment variable is set,
>   SCons will cache the results of past calls to vcvarsall.bat to
>   a file; integrates with existing memoizing of such vars.
> - Preliminary Python 3.9 support.
>
>   DEPRECATED FUNCTIONALITY
>
> - Drop support for Python 2.7. SCons will be Python 3.5+ going forward.
> - Remove deprecated SourceCode()
>
>   CHANGED/ENHANCED EXISTING FUNCTIONALITY
>
> - Added check for SONAME in environment to setup symlinks correctly
> (Github Issue #3246)
> - Resolve Issue #3248 - Removing '-Wl,-Bsymbolic' from
> SHLIBVERSIONFLAGS
>   NOTE: If your build depends on the above you must now add to your
> SHLIBVERSIONFLAGS
> - Microsoft Visual Studio - switch to using uuid module to generate
> GUIDs rather than hand rolled
>   method using md5 directly.
>   NOTE: This change affects the following builders' output. If your
> build depends on the output of these builders
>   you will likely see a rebuild.
>   * Package() (with PACKAGETYPE='msi')
>   * MSVSSolution()
>   * MSVSProject()
> - Improve Visual Studio solution/project generation code to add support
>   for a per-variant cppflags. Intellisense can be affected by cppflags,
>   this is especially important when it comes to /std:c++* which
> specifies
>   what C++ standard version to target. SCons will append
> /Zc:__cplusplus
>   to the project's cppflags when a /std:c++* flag is found as this is
>   required for intellisense to use the C++ standard version from
> cppflags.
> - Allow user specified location for vswhere.exe specified by VSWHERE.
>   NOTE: This must be set at the time the 'msvc' 'msvs' and/or 'mslink'
> tool(s) are initialized to have any effect.
> - Fixed Github Issue 3628 - Hardcoding pickle protocol to 4 (supports
> python 3.4+)
>   and skipping Python 3.8's new pickle protocol 5 whose main advantage
> is for out-of-band data buffers.
>   NOTE: If you used Python 3.8 with SCons 3.0.0 or above, you may get
> a a pickle protocol error. Remove your
>   .sconsign.dblite. You will end up with a full rebuild.
> - MSVC updates: When there are multiple product installations (e.g,
> Community and
>   Build Tools) of MSVC 2017 or MSVC 2019, an Enterprise, Professional,
>   or Community installation will be selected before a Build Tools
> installation when
>   "14.1" or "14.2" is requested, respectively. (GH Issue #3699).
> - MSVC updates: When there are multiple product installations of MSVC
> 2017 (e.g.,
>   Community and Express), 2017 Express is no longer returned when
> "14.1" is
>   requested.  Only 2017 Express will be returned when "14.1Exp" is
> requested.
>   (GH Issue #3699).
> - MSVC updates: pass on VSCMD_DEBUG and VSCMD_SKIP_SENDTELEMETRY to
> msvc
>   tool setup if set in environment. Add Powershell to default env
>   (used to call telemetry script).
> - Renamed as.py to asm.py and left redirecting tool.  'as' is a
> reserved word and so
>   changing the name was required as we wanted to import symbols for
> use in compilation_db
>   tool.
> - Add no_progress (-Q) option as 

Re: [Scons-dev] bug prune

[Gary Oberbrunner]

I think this would be great. I'll help review the bugs-to-be-closed.

-- Gary

On Tue, Aug 27, 2019 at 8:50 AM Mats Wichmann  wrote:

>
> Just to pull some thoughts together:
>
> there are currently 679 open scons issues on github.
>
> That number drops to 92 if you select only ones which have had a
> modification since the big migration from tigris. Try this query:
>
> is:issue is:open updated:>=2018-02-10
>
> or as a link:
>
>
> https://github.com/SCons/scons/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+updated%3A%3E%3D2018-02-10+
>
> I'm a relative newcomer around here, but I don't see the value of
> showing a ton of historical bugs that aren't being worked on; the newly
> filed ones don't even get a lot of attention - there just isn't a big
> scons team at this point and numerically most current contributors have
> a specific motivation ("itch to scratch" as it were) rather than the
> ability to just generally work on bugs.  To provide more visible focus
> there's already been some discussion of a bug prune.
>
> My suggestion is this:
>
> (a) close all open tigris bugs with a message that includes these items:
>
> * bug is now tracked on github [link]
> * bugs which have not had activity in 18 months are going to be closed
> (it doesn't have to be 18, but that was the cutover time)
> * we understand readers of this issue might not see messages from
> github, so if you want to keep this issue alive, make a comment - any
> comment - on the corresponding github issue.
>
> (b) fire up a bot to mark inactive github issues with a tag, and
> configure suitably.  Looks like there's an app in the github marketplace
> that is free so setup is just a YAML file. Example setup here:
>
>
> https://github.com/timgrossmann/InstaPy/commit/afd968dfa1ce1141456a207484d35f2766d5916b
>
> the app:
>
> https://github.com/marketplace/stale
>
> (c) someone scan through the first-time closure proposal list and
> manually update any which seem deserving of continued life.
>
>
> Closed-as-stale issues don't vanish, they are still there to be browsed
> as needed...
>
> ___
> 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

Re: [Scons-dev] [Scons-users] Please try SCons 3.0.4.1 test package

[Gary Oberbrunner]

Works for me with VC 2017 community:

% scons --version
SCons by Steven Knight et al.:
script: v3.0.4.3a41ed6b288cee8d085373ad7fa02894e1903864, 2019-01-20
22:51:36, by bdeegan on kufra
engine: v3.0.4.3a41ed6b288cee8d085373ad7fa02894e1903864, 2019-01-20
22:51:36, by bdeegan on kufra
engine path:
['c:\\tools\\msys64\\msys64\\tmp\\scons-test\\venv\\lib\\site-packages\\scons\\SCons']
% SCONS_MSCOMMON_DEBUG=- scons
scons: Reading SConscript files ...
trying to find VC 14.1
find_vc_pdir_vswhere(): VC found: '14.1'
found VC 14.1
vc.py:get_host_target()
vc.py:get_host_target() req_target_platform:None
_check_cl_exists_in_vc_dir(): host platform amd64, target platform amd64
_check_cl_exists_in_vc_dir(): checking for cl.exe at C:\Program Files
(x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64\cl.exe
_check_cl_exists_in_vc_dir(): found cl.exe!
...
installed_vcs:['14.1']
msvc_setup_env: using default installed MSVC version '14.1'

It didn't find any SDK but I don't think I have one installed so that's
fine.

-- Gary




On Tue, Jan 22, 2019 at 1:44 PM Mats Wichmann  wrote:

> On 1/21/19 10:31 PM, Bill Deegan wrote:
> > Planning in releasing tomorrow.
> > This should fix the issue with 3.0.3 not finding VS/VC 2017
>
>
> This isn't really directly related. There are multiple README files,
> three of them seem fairly key, and they don't entirely agree on some
> basic things - locations for further interaction.
>
> README.rst
> README-local
> src/README.txt
>
> I can prepare a simple patch to align them a bit more, but a couple of
> questions:
>
> * some refer to posting to scons-users and some to scons-dev before
> filing a bug.  Is there an actual delinination between the two that
> should be mentioned, or is it just send to scons-users?
>
> * is the announce list (at tigris) still alive?  it's referred to in
> these three, and the website, but hasn't apparently had a posting since
> 2011 according to its own page.
>
> This is not crucial to any release, and certainly not this one, in my
> opinion, just asking before I forget.
> ___
> 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

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Gary Oberbrunner]

Russel says:

Python 2 is the millstone for SCons 3.

I've been using 3.6 for all recent projects and loving it (async,
f-strings, etc.), but what weight are we really carrying by supporting 2.x?
Seems to me like most 3.6 features can be detected at runtime while still
keeping back compat without too much extra work. But I may be missing
something.

-- Gary

On Sat, Jul 21, 2018 at 7:37 AM Russel Winder  wrote:

> On Fri, 2018-07-20 at 23:20 -0400, Bill Deegan wrote:
> > Pretty certain Gary's with me in saying,
> > SCons will support Python 2.7 and 3.5+ in (at least) the 3.x
> > releases.
> > Most likely through (at least) the end of 2018.
>
> You can add me to agreeing with that.
>
> > I know many who actively participate in SCons community live on the
> > leading
> > edge of OS and Python releases but many users do not.
> > Also, there are still some rough edges to our Python 3 support. Until
> > it's
> > rock solid (and no one has found an issue for a while), dropping py
> > 2.7
> > would be unwise.
>
> I see your finger pointing at me. :-)
>
> We have had not dissimilar maintenance debates in the Apache Groovy
> community, especially now JDK is updated every 6 months instead of
> every 6 years. Clearly there is a need to support people using ancient
> three year old systems. Debian Stable and Ubuntu LTS really set the
> timescales here, and the Python versions. Except that Travis-CI appears
> to think using the most ancient Ubuntu LTS they can is a good thing.
>
> But then come the issues at the heart of the matter: If people are
> using three or five year old platforms, will they be using the very
> latest version of SCons? If they want the very latest SCons why can't
> they install the very latest Python? If they are happy with the three
> year old Python will they actually be happy with the three year old
> SCons? If a distribution provides Python and SCons why is there any
> interest in them updating anything?
>
> Groovy used to have a "we must be totally backward compatible"
> obsession that was over the top, especially for me. Over the last year
> the policy has changed towards something much better, and which has
> allowed Groovy to progress much better in a highly dynamic world.
>
> OK so Java has the big difference that you distribute compiled
> artefacts and there are only link time issues, whereas Python is
> distributed as source so everything is compile time issues. But the
> Groovy team have now begun to accept that "backward compatibility" can
> be taken too far. For each major version of Groovy a lower limit is now
> set and if people are not prepared to update their Java, then they have
> to use the last version of Groovy that works with that version of Java.
>
> Python 2 is the millstone for SCons 3. The question is whether there
> will be a 2.7.16 or whether 2.7.15 is really the last version. Also
> will an organisation break ranks with PSF policy and pick up Python 2.7
> and keep it going? Would that matter for SCons?
>
> I can fully understand sticking with 3.5 at this time, but SCons
> versions must be allowed to change the minimum Python version. Should
> SCons 3.1 require Python 3.6 and drop support for Python 2.7? If yes
> then people not on Python 3.6 simply stay with SCons 3.0.X.
>
> For me this is all about consistency: you can't demand cutting edge
> SCons unless you are prepared to use cutting edge Python.
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
> ___
> 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

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Gary Oberbrunner]

Pretty certain Gary's with me in saying,
SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
Most likely through (at least) the end of 2018.


Yes, absolutely. SCons is used by lots of people on older legacy systems.
IMHO it is and needs to be a solid, reliable build tool, not (just) a
leading-edge dev tool.

-- Gary


On Fri, Jul 20, 2018 at 11:27 PM Bill Deegan 
wrote:

> Pretty certain Gary's with me in saying,
> SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
> Most likely through (at least) the end of 2018.
>
> I know many who actively participate in SCons community live on the
> leading edge of OS and Python releases but many users do not.
> Also, there are still some rough edges to our Python 3 support. Until it's
> rock solid (and no one has found an issue for a while), dropping py 2.7
> would be unwise.
>
>
> -Bill
> SCons Project Co-Manager.
>
> On Fri, Jul 20, 2018 at 4:11 PM, Jonathon Reinhart <
> jonathon.reinh...@gmail.com> wrote:
>
>> > True but who uses Debian Stable for anything relating to software
>> > development, it is a server distribution.
>>
>> I'm not sure where you got the idea that Debian is a "server
>> distribution". Lots of people use Debian as a desktop OS, and my team
>> uses Debian for software development.
>>
>> I think SCons would be making a serious mistake if it dropped support
>> for Python 3.5. Just because the distro is using an older version of
>> SCons, doesn't mean that SCons shouldn't support the latest version of
>> Python available on the system.
>>
>> This is particularly troublesome for me as I consider putting together
>> a new build image, based on Debian 9, but with latest SCons installed
>> from source.
>>
>> I'm all for cleaning up old cruft, but it seems like removing support
>> for a version of Python that's less than 3 years old seems a bit
>> aggressive.
>> ___
>> 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
>


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

Re: [Scons-dev] Where does scons determine the dependencies for object files?

[Gary Oberbrunner]

The builder, in this case Object(), sets up the dependency between foo.o
and foo.c. The simplest way to do what you want is to create a
pseudo-builder that calls Object() and also calls Depends().

-- Gary

On Sun, Mar 25, 2018 at 1:07 PM, Andrew C. Morrow  wrote:

>
> I'm fairly clear on where SCons learns of the dependencies for source
> files: that is in the CScanner attached to the SourceFileScanner in T
> ool/__init__.py.
>
> But where does SCons determine the dependencies of object files, such that
> those dependencies are checked to see if the object file needs to be
> rebuilt?
>
> More concretely, If I have libfoo.so made from foo.o made from foo.c
> which depends on foo.h, the CScanner in SourceScanner takes care of
> scanning for dependences in foo.c and finds foo.h. But what scans for
> dependences of foo.o and identifies foo.c?
>
> I ask because I would like to sometimes inject a new source-like
> dependency into compilations, such that foo.o will depend on not just
> foo.c but also some other file magic, such that if magic is changed then
> foo.o will need to be rebuilt.
>
> With such a mechanism, it would be possible to teach SCons that if an
> AddressSanitizer blacklist file known to be on the compile line like
> -fsanitize-blacklist=path/to/magic is referring to a blacklist file that
> is more up to date than the object file, then the object file should be
> rebuilt.
>
> Thanks,
> Andrew
>
>
>
>
> ___
> 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

Re: [Scons-dev] [Scons-users] Github Project renamed from SConsProject to SCons

[Gary Oberbrunner]

Nice work Anatoly and Bill!

-- Gary

On Thu, Nov 23, 2017 at 6:05 AM, anatoly techtonik 
wrote:

> Awesome. ) More proposals from my side.
>
> 1. SCons repos need `scons` label to compete in this list:
> https://github.com/topics/scons
>
> 2. SCons website need to be moved to GitHub as well:
> https://bitbucket.org/scons/scons-new-website
> https://bitbucket.org/scons/scons-website
>
> This should probably be killed:
> https://bitbucket.org/scons/scons-pelican-bootstrap3
>
> On Wed, Nov 22, 2017 at 10:00 PM, Bill Deegan 
> wrote:
> >
> >
> > On Wed, Nov 22, 2017 at 9:46 AM, Bassem Girgis 
> wrote:
> >>
> >> This is great news. I would recommend consolidating all the online
> >> references to the new repo. Also what is the role of the bitbucket
> repo? The
> >> user contribution builders also need some sorting. I would be more than
> glad
> >> to help in any activity.
> >
> >
> > Where are you seeing references to the bitbucket repo?
> > Most likely they should all be changed.
> >
> > At this point the bitbucket repo is just historical.
> > There are some outstanding pull requests which have yet to be migrated to
> > github.
> >
> > -Bill
> >
> >>
> >>
> >> Best regards,
> >> Bassem
> >>
> >> 
> >> Bassem Girgis, PhD
> >> Cell: +1(256)479-6124
> >>
> >> On Nov 22, 2017 10:48 AM, "Eric Fahlgren" 
> wrote:
> >>>
> >>> Special thanks to you, Bill, and all the others for reviving SCons and
> >>> bringing it back to active life!  It made my life so much easier being
> able
> >>> to continue using SCons as part of our migration to Python 3.  I had
> been
> >>> right at the start of attempting to convert our build system over to
> CMake
> >>> when the stable 3.0 port came out, which saved me untold hours (or
> days or
> >>> weeks) of converting our build system, some parts of which are almost
> 20
> >>> years old now.
> >>>
> >>> Eric
> >>>
> >>> On Wed, Nov 22, 2017 at 7:11 AM, Bill Deegan <
> b...@baddogconsulting.com>
> >>> wrote:
> 
>  Special Thanks to Anatoly for tracking down the previous owner of
>  "SCons" and asking him to change thus freeing up SCons.
> 
>  Special Thanks to Steve Constable (formerly SCons on github) for
>  changing his github user id to free up SCons!
> 
>  You will have to update your remote settings under git.
> 
>  Assuming "upstream" was the remote name you're using to point at the
>  master SCons repo, the following command will update your git sandbox.
> 
>  git remote set-url upstream g...@github.com:SCons/scons.git
> 
>  I'll be updating various bits of SCons wiki, buildbot, and website
> today
>  to make sure they are all pointing at the proper (changed) URLs.
> 
>  -Bill Deegan
>  SCons Project Co-Manager
> 
> 
> 
> 
>  ___
>  Scons-dev mailing list
>  Scons-dev@scons.org
>  https://pairlist2.pair.net/mailman/listinfo/scons-dev
> 
> >>>
> >>>
> >>> ___
> >>> Scons-users mailing list
> >>> scons-us...@scons.org
> >>> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >>>
> >>
> >> ___
> >> Scons-users mailing list
> >> scons-us...@scons.org
> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >>
> >
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
>
>
>
> --
> anatoly t.
> ___
> 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

Re: [Scons-dev] D tool development workflow

[Gary Oberbrunner]

Ha, I can hardly call myself a "core activist" anymore, but thanks. :-)

On Fri, Apr 21, 2017 at 1:28 PM, Russel Winder <rus...@winder.org.uk> wrote:

> On Fri, 2017-04-21 at 12:55 -0400, Gary Oberbrunner wrote:
> >
> […]
> >
> > I would be so happy about this. I would gladly volunteer to help. I'm
> > all
> > git+github for literally everything else, home & work.
>
> I think I have been tainted by Apache do-ocracy from association with
> Apache Groovy: to those that do is given the power to decide.
>
> Given that the two core activists want change form Mercurial to Git,
> then that change should happen.
>
> --
> 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
>
>


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

Re: [Scons-dev] D tool development workflow

[Gary Oberbrunner]

On Fri, Apr 21, 2017 at 12:41 PM, Bill Deegan 
wrote:

> That said, I'm thinking post 3 a migration to github could have some real
> value.
> (And git, I'm tired of using HG on only this project)


I would be so happy about this. I would gladly volunteer to help. I'm all
git+github for literally everything else, home & work.


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

Re: [Scons-dev] [Scons-users] Can we drop windows native installers if pip install works?

[Gary Oberbrunner]

As a Windows user, I'd be very happy if pip install were the only proper
way to install it going forward. Yes, sometimes I'd want to do it locally,
but using pip is fine.

On Mon, Apr 10, 2017 at 8:15 AM, Jonathon Reinhart <
jonathon.reinh...@gmail.com> wrote:

>
> On Mon, Apr 10, 2017 at 3:36 AM, Alexandre Feblot <
> alexandre.feb...@gmail.com> wrote:
>
>> And in some controlled environments, there might be no access to
>> internet. A self contained installer is still the best solution in this
>> situation.
>
>
> That's not an issue. Pip will happily install from a zip file, tarball,
> cloned git repo, etc. There is no internet access requirement to use Pip.
>
> A lot of Windows users will, out of habit, come looking for "setup.exe",
> but considering Pip comes pre-installed with Python 2.7 and up these days,
> it'd be trivial to 'pip install scons'.
>
> ___
> 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

Re: [Scons-dev] Accommodating dependency cycles.

[Gary Oberbrunner]

On Wed, Mar 22, 2017 at 10:47 PM, William Blevins 
wrote:

> Here is another one. I assume this round of issues is because they updated
> SCons on the latest Ubuntu. This one actually makes sense. Someone else
> posted this one. "test2.h" explicitly depends on "test.h" via Command
> Builder, and "test.h" implicitly depends on "test2.h" via scanner.


except not quite: the scanner makes (or *should* make) anything *compiled
from* test.h (e.g. test.obj) depend on test2.h. test.h has no dependencies;
it's a source. As perhaps you noted above, it seems like the Command
builder is somehow running the C scanner, but shouldn't. If the Command in
this example had been an Object or Program whose target was still called
test2.h, then there would be a real dependency loop (because test.h
includes test2.h, SCons shouldn't compile test.h into the result object
until test2.h is up-to-date, and the result "object file" in that case is
called test2.h).

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

Re: [Scons-dev] Accommodating dependency cycles.

[Gary Oberbrunner]

On Wed, Mar 22, 2017 at 6:15 PM, William Blevins 
wrote:

> //source.cpp
> #include "source.gen.h"
> int main() { return 0; }
>
> //SConstruct
> e = Environment()
> e.Command("source.gen.h", "source.cpp", Copy('$TARGET', '$SOURCE')) #
> "generator"
> e.Program("source.cpp")
>
> This code works fine in Scons 2.1, but Scons 2.5.1 produce error:
> scons: *** Found dependency cycle(s):
>   source.gen.h -> source.gen.h
>
> If I'm reading this correctly, I don't see a cycle.
"source" depends on source.cpp and source.gen.h.
source.gen.h depends on source.cpp.
source.cpp is a source, doesn't depend on anything.
Now source.gen.h includes itself, which is weird, but shouldn't all by
itself cause a loop as long as the scanner knows it's already seen that
file.
source.gen.h should definitely not depend on itself.

(Not saying the current code doesn't detect a cycle, just that in the
abstract there shouldn't actually be one.)


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

Re: [Scons-dev] Proposal for SCons documentation on StackOverflow...

[Gary Oberbrunner]

Looks like I was the final vote!

On Jul 30, 2016 7:35 AM, "Dirk Bächle"  wrote:

> Hi there,
>
> for the beta phase of the new StackOverflow documentation, SCons is now
> also proposed...to make this happen we need 5 committers accepting the
> proposal. Two (myself included) have already given their vote, and it would
> be cool if anyone who's active in StackOverflow clicks the "Commit" button
> too.
>
> As far as I understand it, this doesn't mean that the accepting person has
> to actively participate in writing and maintaining SCons documentation, but
> supports the idea in general.
>
> Here's the direct link:
>
>   http://stackoverflow.com/documentation/scons/commit
>
> and thanks in advance for your contribution.
>
>
> Best regards,
>
> Dirk
>
>
> P.S.: My idea behind this is to actively use StackOverflow to collect
> simple examples and usage schemes, that could then get added to the
> UserGuide later on, if appropriate. Further, it would lower the barrier for
> people that don't want to deal with our documentation toolchain. Having to
> tackle only standard markdown syntax should bring forth a number of
> contributors in the area of documentation. This will definitely help the
> project in the long run... ;)
> ___
> 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] no more print statements in SConscripts?

[Gary Oberbrunner]

Hi folks; I know I've been out of the loop recently, lots going on. Great
work getting the python 3 stuff in!

I did just try the default branch (with python2.7 on Windows) and I notice
print statements (not the function, just the statement) in
SConstructs/SConscripts are now syntax errors. This'll probably be a big
change for users. Just FYI.

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

Re: [Scons-dev] Hg vs Git

[Gary Oberbrunner]

It would certainly make it easier for me to contribute; not that I've had
that much to contribute recently, but git is in my fingers now and I have
to remind myself how to do things in hg.

On Mon, May 9, 2016 at 1:13 PM, Bill Deegan 
wrote:

> All,
>
> So it sounds like (from limited consensus), that switching to Git now,
> would remove a significant barrier to contributing code/fixes?
>
> -Bill
>
> On Mon, May 9, 2016 at 8:12 AM, Tim Jenness  wrote:
>
>>
>> > On May 9, 2016, at 07:57 , Rob Boehne  wrote:
>> >
>> > For me, scons is the ONLY project I work on that uses Mercurial, and
>> > having to translate each and every command is a real pain.
>> > I¹ve also NOT contributed back many changes I¹ve made to get Python to
>> > build properly on old UNIX systems, primarily because it was using Hg.
>> >
>> > I doubt I¹m alone in this, and I¹m certain it¹s a lot easier to find a
>> > competent developer who knows Git but has never used Mercurial than the
>> > other way around.  This is an extra effort for most developers, and that
>> > extra effort will get more common, and more painful as the years go by.
>> > IMHO switching to Git is a clear win.
>> >
>>
>> I have to agree. Whilst I am really interested in helping with the python
>> 3 port the hg hurdle has just meant I haven’t found the time. I have too
>> many other things pulling at me that I can do easily with my git workflow.
>>
>> —
>> 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
>
>


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

Re: [Scons-dev] Python 3 strategy

[Gary Oberbrunner]

On Mon, Jan 25, 2016 at 4:39 AM, Russel Winder  wrote:

> The alternative is to abandon the current python3-port and start again
> from default based solely on future.
>

This doesn't seem crazy to me, although there was a LOT of hand-tweaking of
code on the current python3 branch: utf8/locale stuff, print stmts, which
in a fair number of cases didn't look like any automation would've caught
them. So if you start again I suspect most of that work will have to be
redone. I spent a couple of days on it, iirc, and I wasn't the only one.
Maybe some of those changes could be cherry-picked over? I suggest skimming
some of my changes on that branch (not the merges, just the by-hand stuff)
to get a sense of what had to be done.

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

Re: [Scons-dev] Python3 activity

[Gary Oberbrunner]

On Fri, Jan 15, 2016 at 8:24 AM, Russel Winder  wrote:

> Aim is still to get the code-base working properly, i.e passing all
> tests, as a Python 2.7 program, so that it can then become the default
> branch. My thinking here is that if we do not have a separate branch,
> but instead are evolving default to be Python 3 compatible as a Python
> 2.7 codebase then Python 3 usage will happen faster. The "down side" is
> that all Python 2 code must be written with Python 3 compliance from
> merge time on on, this includes all pull requests.
>
>

I'm absolutely in agreement with this as our forward-looking plan, once the
initial hump is surmounted.


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

Re: [Scons-dev] new website update and added badges to readme for repo

[Gary Oberbrunner]

LGTM!

On Thu, Jan 14, 2016 at 2:10 PM, Bill Deegan 
wrote:

> All,
>
> If you get a chance, take a look:
> http://scons.org/new/
> and
> https://bitbucket.org/scons/scons
>
> The badges take a few seconds to render (on my currently very crappy
> internet connection)
>
> Unless I hear lots of reasons not to, I'm going to roll out the new
> website over the weekend.
>
> -Bill
>
> ___
> 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

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

[Gary Oberbrunner]

On Sun, Jan 10, 2016 at 4:26 AM, Dirk Bächle  wrote:

> On 09.01.2016 20:47, Bill Deegan wrote:
>
>> Dirk,
>>
>> For me, its "pain in having to remember how to do things in mercurial
>> which I only use for scons" each time I go to work on it I
>> have to refresh my mental cache.
>> Which I'm pretty sure wouldn't be measurable by such statistics. But (at
>> least for me) would increase the amount of fun it is to
>> work on the project.
>>
>>
> and this (I'm referring to the "increased fun" here) wouldn't result in
> "more commits" and "more bugfixes"? Jonathon Reinhart stated this point in
> his mail explicitly: more git -> more commits.


This is my situation as well -- SCons is the only project I contribute to
that still uses hg, and since I use git everywhere else I've become pretty
expert at it. It's in my fingers and I don't even think about it anymore. I
also have dozens of git aliases and config tweaks so I go pretty fast with
it. There is of course also the better data model, but of course that's
arguable so I'm only mentioning my personal situation -- but I suspect I'm
not unique. So would switching lead to more commits and bugfixes? I can't
say for sure but from what I've seen in hiring developers, almost everyone
knows git and puts it on their resume, and I only rarely see hg experience.
So it _might_ make it easier for other contributors.

As for using a git-hg bridge, that would help local usage for us git users,
but it doesn't change the underlying branching model. If it's decided not
to switch, I might consider trying that.

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

Re: [Scons-dev] Code of conduct?

[Gary Oberbrunner]

It's OK with me. As I said at the beginning I'd prefer something broader
and less specific but I didn't find anything useful.

On Tue, Dec 29, 2015 at 2:29 PM, Bill Deegan 
wrote:

> All,
>
> So are we good with:
> http://contributor-covenant.org/
>
> If so I'll add it to the new website.
>
> -Bill
>
> On Tue, Dec 29, 2015 at 12:39 AM, Dirk Bächle  wrote:
>
>> Anatoly,
>>
>> Am 28.12.2015 um 15:33 schrieb anatoly techtonik:
>>
>>> [...]
>>>
 I'm not sure why you're objecting to this unless you think you are
 likely to
 violate a CoC..

>>> Because following CoC makes people CoC-followers, which is offensive for
>>> some. Don't be a jerk rule is good enough and the rules should be applied
>>> only when they are needed on personal basis.
>>>
>>> I am against CoCs. It makes me feel regulated and I am sick and tired of
>>> that,
>>> so I likely to act against it and you have to ban me.
>>>
>> feel free to "act against it", but "filibustering" (refer to
>> http://www.merriam-webster.com/dictionary/filibuster and optionally
>> https://www.youtube.com/watch?v=Q52kFL8zVoM ) won't help. We've already
>> reached consensus to have a simple CoC and are simply ironing out the last
>> details.
>>
>> @all: Are we ready to move on with this one and take some action? I am...
>>
>> Best regards,
>>
>> Dirk
>>
>> P.S.: Nobody wants to ban you. We'll simply continue with our plan and
>> are ready to face the consequences of you getting "sick and tired" about
>> feeling regulated again...
>>
>>
>> ___
>> 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
>
>


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

Re: [Scons-dev] SCons and Python 3

[Gary Oberbrunner]

Hi Russel; last time I did this it wasn't all _that_ painful. Took a few
hours if I remember rightly. (Of course a lot of time has passed, but still
not that much new code compared to the entire code base.) Look at the diff
of the last merge before you start, to get a sense of the top two or three
things that have to get tweaked.

On Sat, Dec 19, 2015 at 4:39 AM, Russel Winder  wrote:

> On Wed, 2015-12-16 at 09:22 +0100, Dirk Bächle wrote:
> >
> […]
> > @Russel: If all Buildbots turn out to be "green", feel free to merge
> > onto the python3 branch...
>
> It appears as though Windows is still a bit red, but I cannot in all
> honest profess any sadness. As all the Linux variants are green, I
> shall take this as a "go" to do a merge to the Python 3 branch. This
> will undoubtedly lead to a right royal mess, but then that is the whole
> point – fix the mess.
>
> My assumptions will be:
>
> Python 3.4 and 3.5
> Python 2.7.10
> Debian Sid
> Fedora Rawhide
> No packages not in the standard distribution
> A lack of CI to cover Solaris, OSX or Windows
>
> I may be gone a while…
>
> Progress will be reflected in  https://bitbucket.org/russel/scons__pyth
> on3
>
> Should anyone track progress and want to chip in feel free. If you see
> any lack of progress, it will either be me having to work on organizing
> ACCU 2016 (accu.org) or choosing to work for a while on GPars or Me TV
> – or eating and especially drinking, it is Christmas after all. Do not
> drink and code.
>
> --
> 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
>
>


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

Re: [Scons-dev] Code of conduct?

[Gary Oberbrunner]

I'm in favor of something like this. It's really important to be a
welcoming and inclusive community. I don't think having a code of conduct
is any kind of admission of failure; rather I see it as a proactive
statement of inclusiveness and professionalism. I wonder if a broader code
of conduct wouldn't make sense as well, covering general ethics
(intellectual property, honesty, integrity, objectivity, humility,
transparency, conflicts of interest, etc.) and professional behavior as
well as some of the specific coverages in the CC? Anyone know of examples
of such things that might apply to a group like ours? Of course lawyers,
doctors, and engineers have such codes but they tend to be lawyery and
overdone. I'd almost be in favor of just "don't be a jerk" but I think that
doesn't work for the people it most needs to work for. What about e.g.
http://yahoo.github.io/codeofconduct?

On Fri, Dec 4, 2015 at 12:10 PM, Bill Deegan 
wrote:

> All,
>
> Perhaps it's a good idea to add an official code of conduct for SCons.
>
> http://blog.codinghorror.com/the-hugging-will-continue-until-morale-improves/
>
> The following site seems to provide a reasonable code.
> http://contributor-covenant.org/
>
> Thoughts?
>
> -Bill
> p.s. as an aside I also work on Buildbot and they applied for an open
> source grant through Mozilla's $1M grant program. One of the questions was
> "Do you have a code of conduct".
>
> ___
> 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] Configure(), dependencies, and Variant dir

[Gary Oberbrunner]

Does anyone know how these interact?

I have a TryBuild test in a Configure context. It uses a variant dir. The
.c file in the test includes foo.h, which includes bar.h. If I have a
previous build (which copied bar.h into variantdir) and then update bar.h,
the TryBuild uses the old variantdir/bar.h without copying the new version
to the variant dir first as it should. The regular part of the build works
fine, it's just the SConf part.

I suspect something in the dependency tracking logic isn't fully
implemented in configure context; does this seem familiar to anyone before
I dig into it further?

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

Re: [Scons-dev] Python 3 branch

[Gary Oberbrunner]

I didn't think it had been that long... I'll check my records.

On Sat, Nov 7, 2015 at 3:20 AM, Russel Winder  wrote:

> Gary,
>
> From what I can see the last merge from default into python3-port was
> 2014-08-23. A lot has happened since then. :-)  Is the best way forward
> to do a merge, deal with the fall out, and see where we are?
>
> --
> 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
>
>


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

Re: [Scons-dev] SCons tools refactoring progress

[Gary Oberbrunner]

Comments inline.

On Tue, Oct 20, 2015 at 12:52 AM, anatoly techtonik <techto...@gmail.com>
wrote:

> On Tue, Oct 20, 2015 at 3:57 AM, Gary Oberbrunner <ga...@oberbrunner.com>
> wrote:
>>
>> On Sun, Oct 18, 2015 at 7:52 AM, anatoly techtonik <techto...@gmail.com>
>> wrote:
>>
>>>
>>> I see the implementation, but I don't see any use cases. I know it
>>> sounds too formal, but I can't validate the assumptions we had towards the
>>> new toolchain without a formal list. Do you have some notes or maybe BDD
>>> tests for that?
>>>
>>
>> A very good question. I don't have enough design notes in there; I'll
>> write up some of my motivations and design goals here and add them to the
>> README.rst.
>>
>> The basic idea is that the current concept of a Tool is too low level;
>> the primary motivating use case is that users (SConscript authors) should
>> be able to select groups of related tools, _as_ a group, with fallbacks. A
>> Toolchain is that abstraction.
>>
>
> The use case is already good to be recorded. But there are two cases:
> 1. Select a group of related tools
> 2. Fallback
> Do we have a concrete groups of related tools already?
>

Yes, I described a few. (Compiler and linker, maybe assembler is the
obvious one.)


> The fallback story needs to be expanded. Are there fallback choices inside
> of one group (with priority or other preference strategy) or the fallback
> means "fallback to another group"? Maybe I am too detailed, but also - what
> are the cases when fallbacks occur?
>

This is all implemented. Check the code and test cases (Toolchain-test.py).
I think it's pretty solid but please review. Basically it's recursive AND
and OR trees with optional or required elements.


> It it not necessary to design everything now upfront - the primary goal of
> my questions is to find *real world* stories (not even use cases) for which
> new mechanism is needed. I am afraid to design a system that will be too
> perfect for implementation in a free time.
>

Well, at least for the toolchain, I think it's mostly there
implementation-wise (check it out). The interesting stuff is improving the
Tool ideas (there's a sort of registry so you can give concrete tools names
and look them up that way), adding Finders, and all the other stuff that
we've been discussing. But if you have some real-world stories you'd like
to see covered, this is a good time to get them out there.

All the rest is just there to make that idea work well. The secondary goal,
>> in service of the main one, is that Tools need to obey their abstraction,
>> for instance always calling exists().
>>
>
> What is the story behind this? Because I know the opposite story -
> exists() for default tools is called even if I don't build anything with
> those tools - this delays the build start and produces messages about
> missing compiler to the screen.
>

exists() is how a tool knows whether its binaries (or whatever it needs to
run) exist or not, so toolchains can't work without it. As for default
tools, the idea here is that SConscript writers will (finally!) be able to
specify exactly which tools they want. I hope to do away with the current
default tool initialization system, though some of that still needs to be
thought out. The current design is much "lazier" but still needs work.

The new system also creates a distinction between an abstract tool, such as
>> intelc, and a concrete instance of it, such as intelc v12 x86. This is
>> needed so the user can create chains of either specific or general tools.
>>
>
> I understand where this might be useful, but still - is there a real world
> story where this was needed?
>

Absolutely - in my day job we specify very carefully what tool chain is
used to build any given product. If the machine doesn't have the right
version of the Intel compiler the build should fail. For open-source
projects, on the other hand, they should try to build on as many
configurations as possible so they want to keep things general -- use any
Intel compiler, or any gcc, or any cc (for instance).


> One restriction I'm imposing in the new system is that Tools have to be
>> configurable outside of any Environment; I don't like the current system
>> where tool-configuration variables ("tool args" basically) are mixed into
>> the Environment. This poses some challenges for a fully generalizable
>> system but I think I have a decent handle on that. The current Intel
>> compiler has an initial attempt at such tool args.
>>
>
> How to handle "tools args" is a question for a separate thread. We will
> need to have a standard set for every *type* of tool and specific for eve

Re: [Scons-dev] SCons tools refactoring progress

[Gary Oberbrunner]

On Sun, Oct 18, 2015 at 7:52 AM, anatoly techtonik 
wrote:

>
> I see the implementation, but I don't see any use cases. I know it sounds
> too formal, but I can't validate the assumptions we had towards the new
> toolchain without a formal list. Do you have some notes or maybe BDD tests
> for that?
>

A very good question. I don't have enough design notes in there; I'll write
up some of my motivations and design goals here and add them to the
README.rst.

The basic idea is that the current concept of a Tool is too low level; the
primary motivating use case is that users (SConscript authors) should be
able to select groups of related tools, _as_ a group, with fallbacks. A
Toolchain is that abstraction. All the rest is just there to make that idea
work well. The secondary goal, in service of the main one, is that Tools
need to obey their abstraction, for instance always calling exists(). The
new system also creates a distinction between an abstract tool, such as
intelc, and a concrete instance of it, such as intelc v12 x86. This is
needed so the user can create chains of either specific or general tools.
One restriction I'm imposing in the new system is that Tools have to be
configurable outside of any Environment; I don't like the current system
where tool-configuration variables ("tool args" basically) are mixed into
the Environment. This poses some challenges for a fully generalizable
system but I think I have a decent handle on that. The current Intel
compiler has an initial attempt at such tool args.

Some use cases:
 * a simple SConstruct should automatically select the "best"
compiler/linker
 * a non-C-related SConstruct (e.g. doc prep, asset management, scientific
data handling) shouldn't have to care about compilers, linkers or other
unrelated tools
 * a SConstruct author should be able to specify toolchains and
alternatives, and handle failures gracefully
 * it should be possible to write a SConstruct where the tools and
toolchains can be manipulated by cmd line args if desired
 * it should be possible to specify desired tools generally ("gcc/gnulink")
or very specifically ("gcc 4.3, x86 cross compiler, with gnulink 4.3 - and
TeXLive")

There's a bunch of tests in that dir; they're mostly unit-test level at
this point. There are also some examples of the new subsystem in use (see
the README) which are closer to actual use cases.

My current task is to design a good way for Tools to find their executables
and configure themselves. The current ad-hoc method is not consistent and
doesn't encourage reuse. Jason has some ideas in Parts (see its concept of
Finders); I don't intend to reuse that directly but at least take some
inspiration from it. My current design I'm working on is something like
this: ... a good architecture might be to have a list of finders, to be
tried in order; each one can be any type (env, reg, path, fixed path,
function, whatever); build a list of all the results, and then have a
finder-picker that picks the best from that list (the simplest
finder-picker might be return paths[0]). But where that list comes from and
how it's manipulated is still TBD.

Additionally I'd like to see how far it makes sense to go in having
standard args to configure Tools; one way is just to leave args up to each
Tool (but maybe have the Finders have some high-level control); the other
is to define many standard ones (like ARCH, search in PATH or some custom
path, and so on) - the latter will make it easier someday to pass these all
the way down from the cmd line. I want Tools (and their Toolchains) to
stand alone easily, but also have some way to override their decisions at a
high level (globally, from cmd line, etc.)

And yes, with this system it is a goal that there would be no more "missing
Visual Studio" errors on Windows. :-)

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

Re: [Scons-dev] SCons tools refactoring progress

[Gary Oberbrunner]

I'm just starting to get back into it.
If you'd like to take a look at the current state of things, check out
h...@bitbucket.org/garyo/scons-newtool and look in
src/engine/SCons/ToolchainDesign.
The next thing on my list for it is a nice generalized executable-finder
(PATH, registry, env, hard-coded, etc.)
Any feedback much appreciated!

On Tue, Oct 13, 2015 at 6:09 PM, Bill Deegan 
wrote:

> Vasily,
>
> I think Gary was working on that. Work's ongoing.
> It's not imminent to be merged into main.
>
> Are you volunteering to help?
> ;)
>
> -Bill
>
> On Tue, Oct 13, 2015 at 2:29 PM, Vasily  wrote:
>
>> Hi all!
>>
>> I recall there were some plans on refactoring how Tools work in SCons.
>> Are there any news on that?
>>
>> Thanks,
>> Vasily
>>
>> ___
>> 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
>
>


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

Re: [Scons-dev] Proper way to get File path (undocumented rfile)

[Gary Oberbrunner]

str(File) just calls f.path. There are also plenty of other attributes like
fullpath. Sometimes f.srcnode().path is useful. Most are documented, see
File and Directory Nodes in the man page. The ones that aren't (like rfile)
are intended for internal use but may occasionally still be useful.  See
the API docs at
http://www.scons.org/doc/latest/HTML/scons-api/SCons.Node.FS.File-class.html
for gory details.

-- Gary

On Fri, Oct 2, 2015 at 10:07 AM, Jonathon Reinhart <
jonathon.reinh...@gmail.com> wrote:

> I, too have come across scenarios where rfile() was the only way to
> accomplish exactly what I needed. I believe the scenario was this:
>
> The arguments / command-line parameters to my external utility were so
> complex, SCons couldn't handle it himself. So I wrote my own
> variable-function-thing (like ${_concat}) in which I needed to expand the
> Nodes to their paths, just like SCons would when expanding $TARGETS to
> their paths. This is how I ended up finding rfile().
>
> It seems like it should be documented.
>
>
>
>
>
> On Fri, Oct 2, 2015 at 4:15 AM, anatoly techtonik 
> wrote:
>
>> Hi,
>>
>> Currently the way to get filename from File node is to str() that File.
>> That's quite shady API, especially if used in function like:
>>
>> def convert(node):
>> return str(node).replace('\\', '/')
>>
>> I mean you have no idea what types of node are expected and why
>> there is slash escaping. The str(node) can return anything and
>> works on any types of nodes.
>>
>> So, there is undocumented method File.rfile() with the path.
>>
>> http://www.scons.org/doc/HTML/scons-api/SCons.Node.FS.File-class.html#rfile
>> Which contains os specific path and it is used for example in
>> https://github.com/wesnoth/wesnoth/pull/481/files
>>
>> The questions.
>> 1. Why it is called rfile?
>> 2. Should it be documented?
>> 3. What should be the proper API to get path info for File node?
>> 4. What is the proper API to convert paths to system-specific and to
>> canonical (forward slash) form?
>> --
>> anatoly t.
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
>
> --
> Computers are incredibly fast, accurate and stupid. Human beings are
> incredibly slow, inaccurate and brilliant. Together they are powerful
> beyond imagination.
> A. Einstein
>
> ___
> 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

Re: [Scons-dev] Roundup tracker demo instance...

[Gary Oberbrunner]

got it.

On Thu, Oct 1, 2015 at 2:17 AM, Florian Miedniak <florian.miedn...@gmail.com
> wrote:

> Hm, I knew I forgot someone ;-) You should have got an invitation by now.
>
> -Florian
>
> 2015-10-01 4:14 GMT+02:00 Gary Oberbrunner <ga...@oberbrunner.com>:
>
>> I don't seem to have any access.  "Forgot password" doesn't work with any
>> username I tried...
>>
>> On Wed, Sep 30, 2015 at 4:58 PM, Florian Miedniak <
>> florian.miedn...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have created a on-demand trial setup of the JIRA + bitbucket
>>> integration here: https://scsandbox.atlassian.net with write access to
>>> both parts for Dirk, Gary, Bill Deegan and William Blevins. I'm sure
>>> there's someone I forgot ;-) Just tell me and I'll add you to the users
>>> list.
>>> The very basic integration works:
>>>   - Mention a JIRA issue (SCSAND-) in a commit message and push
>>> it to https://bitbucket.org/scsandbox/jira_bitbucket_integration -> The
>>> issue name will be a hyper-linked to JIRA
>>>  - If you open a JIRA issue on the right there is a section
>>> "Development" which shows all commits belonging to this issue. Here you can
>>> step-wise dive into the commit until you end up on bitbucket's commit view
>>> - It is possible (but not yet configured) to modify the standard JIRA
>>> issue workflow, so an issue e.g. transits to REVIEW to FIXED when a pull
>>> request gets merged. (And there is a ton of other event/notification
>>> configuration options available ...)
>>>
>>> The trial setup is available until 2015/10/6 (due to the trial license),
>>> so feel free to check its look and feel!
>>>
>>> -Florian
>>>
>>> 2015-09-29 8:52 GMT+02:00 Florian Miedniak <florian.miedn...@gmail.com>:
>>>
>>>>
>>>>
>>>> 2015-09-28 21:42 GMT+02:00 William Blevins <wblevins...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 28, 2015 at 7:45 PM, Russel Winder <rus...@winder.org.uk>
>>>>> wrote:
>>>>>
>>>>>> On Mon, 2015-09-28 at 13:56 +0100, William L Blevins wrote:
>>>>>> > […]
>>>>>> > I have used Jira and I think if we can get free instances for the
>>>>>> > project, then the direct jira -> bitbucket <- confluence setup will
>>>>>> > give us a lot of project management control.
>>>>>>
>>>>>> Personally I found Confluence a right royal pain in the arse. JIRA on
>>>>>> the other hand worked very well for me. The issue is whether SCons can
>>>>>> have a JIRA directly linked to the Mercurial repository and its pull
>>>>>> requests.
>>>>>>
>>>>>
>>>>>
>>>>> Since they are all Atlassian products, I cannot imagine "no" to be the
>>>>> answer; otherwise, what is the point?
>>>>>
>>>>>
>>>> William, I agree with you, that it is not the question, *if* there is
>>>> support for connecting bitbucket hosted mercurial repos with JIRA. (
>>>> http://blogs.atlassian.com/2012/07/connect-jira-to-your-git-or-mercurial-repositories-with-the-jira-dvcs-connector)
>>>> It's more the question how mature it is. From my previous experience,
>>>> Atlassian does a quite good job of integrating their products.
>>>> Nevertheless, the best (and IMO only) way to find out, if there are any
>>>> technical / user experiance obstacles left for using JIRA<->Bitbucket for
>>>> Scons, is to give it a try:
>>>> 1. Check for JIRA<->Mercurial on Bitbucket integration with a sandbox
>>>> project
>>>> 2. Adapt the scripts of Dirk to import the existing issues from tigris
>>>>
>>>> I'd volunteer to do this to have a solid basis for further
>>>> decision-making.
>>>>
>>>> -Florian
>>>>
>>>
>>>
>>> ___
>>> 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
>
>


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

Re: [Scons-dev] Roundup tracker demo instance...

[Gary Oberbrunner]

I don't seem to have any access.  "Forgot password" doesn't work with any
username I tried...

On Wed, Sep 30, 2015 at 4:58 PM, Florian Miedniak <
florian.miedn...@gmail.com> wrote:

> Hi,
>
> I have created a on-demand trial setup of the JIRA + bitbucket integration
> here: https://scsandbox.atlassian.net with write access to both parts for
> Dirk, Gary, Bill Deegan and William Blevins. I'm sure there's someone I
> forgot ;-) Just tell me and I'll add you to the users list.
> The very basic integration works:
>   - Mention a JIRA issue (SCSAND-) in a commit message and push it
> to https://bitbucket.org/scsandbox/jira_bitbucket_integration -> The
> issue name will be a hyper-linked to JIRA
>  - If you open a JIRA issue on the right there is a section "Development"
> which shows all commits belonging to this issue. Here you can step-wise
> dive into the commit until you end up on bitbucket's commit view
> - It is possible (but not yet configured) to modify the standard JIRA
> issue workflow, so an issue e.g. transits to REVIEW to FIXED when a pull
> request gets merged. (And there is a ton of other event/notification
> configuration options available ...)
>
> The trial setup is available until 2015/10/6 (due to the trial license),
> so feel free to check its look and feel!
>
> -Florian
>
> 2015-09-29 8:52 GMT+02:00 Florian Miedniak :
>
>>
>>
>> 2015-09-28 21:42 GMT+02:00 William Blevins :
>>
>>>
>>>
>>> On Mon, Sep 28, 2015 at 7:45 PM, Russel Winder 
>>> wrote:
>>>
 On Mon, 2015-09-28 at 13:56 +0100, William L Blevins wrote:
 > […]
 > I have used Jira and I think if we can get free instances for the
 > project, then the direct jira -> bitbucket <- confluence setup will
 > give us a lot of project management control.

 Personally I found Confluence a right royal pain in the arse. JIRA on
 the other hand worked very well for me. The issue is whether SCons can
 have a JIRA directly linked to the Mercurial repository and its pull
 requests.

>>>
>>>
>>> Since they are all Atlassian products, I cannot imagine "no" to be the
>>> answer; otherwise, what is the point?
>>>
>>>
>> William, I agree with you, that it is not the question, *if* there is
>> support for connecting bitbucket hosted mercurial repos with JIRA. (
>> http://blogs.atlassian.com/2012/07/connect-jira-to-your-git-or-mercurial-repositories-with-the-jira-dvcs-connector)
>> It's more the question how mature it is. From my previous experience,
>> Atlassian does a quite good job of integrating their products.
>> Nevertheless, the best (and IMO only) way to find out, if there are any
>> technical / user experiance obstacles left for using JIRA<->Bitbucket for
>> Scons, is to give it a try:
>> 1. Check for JIRA<->Mercurial on Bitbucket integration with a sandbox
>> project
>> 2. Adapt the scripts of Dirk to import the existing issues from tigris
>>
>> I'd volunteer to do this to have a solid basis for further
>> decision-making.
>>
>> -Florian
>>
>
>
> ___
> 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

Re: [Scons-dev] Does SCons test support negative tests?

[Gary Oberbrunner]

On Tue, Sep 29, 2015 at 12:08 PM, Bill Deegan 
wrote:

> Gary,
>
> For this test I ended up just having the full expected output, in this
> case I effectively checked for the output not being there.
> It worked for the negative case because the output is pretty short.
>
> Can you use must_not_contain on stdout?
> I'm thinking our test framework docs are pretty sparse.
>

There's a _small_ amount in the wiki, at
https://bitbucket.org/scons/scons/wiki/DeveloperGuide/TestingMethodology/QMTestMethods
 and
https://bitbucket.org/scons/scons/wiki/DeveloperGuide/TestingMethodology.
The README in the QMTest dir is not all that helpful; that'd be a good
place for some of this IMHO.


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

Re: [Scons-dev] Roundup tracker demo instance...

[Gary Oberbrunner]

On Thu, Sep 24, 2015 at 2:17 PM, William Blevins 
wrote:

> Functionality wise, what does round-up provide that tigris doesn't?


Lack of awfulness.  IMHO of course. :-)

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

Re: [Scons-dev] SCons 2.4.0 Released

[Gary Oberbrunner]

Next thing is to merge default into the python3 branch.  I did this a few
months ago; you can look at the merge to see the kinds of things that have
to be tweaked, it's not usually too bad.

On Tue, Sep 22, 2015 at 3:44 PM, Tim Jenness  wrote:

>
> > On Sep 22, 2015, at 12:33 , Bill Deegan 
> wrote:
> >
> > Tim,
> >
> > Feel free to help out on the python 3 work then.
> >
>
> Ok. Where do I start? (I’m trying to get a buildbot slave set up but the
> process of locating a linux machine is taking a while).
>
> Last time I looked the Python3 branch was a year old. Are we starting from
> current master? Are we committed to six or is future an option (I use
> future in my own projects).
>
> —
> Tim Jenness
>
> ___
> 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

Re: [Scons-dev] sunar tool

[Gary Oberbrunner]

Looks like a bug to me.

On Sun, Sep 20, 2015 at 6:43 AM, Paweł Tomulik 
wrote:

> Hi,
>
> during my work on shared library versioning I found these lines in
> Tools/sunar.py (static library linker, in function generate()):
>
> env['SHLINK']  = '$LINK'
> env['SHLINKFLAGS'] = SCons.Util.CLVar('$LINKFLAGS -G')
> env['SHLINKCOM']   = '$SHLINK $SHLINKFLAGS -o $TARGET $SOURCES
> $_LIBDIRFLAGS $_LIBFLAGS'
>
>
> Does anyone know, why the static library linker (sunar) sets the flags
> of shared library builder? IMHO these should only be touched in
> sunlink.py (default linker on sunos). As for now, the shared library
> flags set in sunlink.py get overwritten by sunar.py which is quite
> confusing.
>
> Best Regards!
>
> --
> Pawel Tomulik
> ___
> 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

Re: [Scons-dev] [Scons-users] SharedLibrary + SHLIBVERSION and cygwin

[Gary Oberbrunner]

Sorry I have been busy.  Will try to this weekend.  Anyone else?

On Tue, Sep 8, 2015 at 5:41 PM, Paweł Tomulik 
wrote:

> Hi,
>
>
> W dniu 01.09.2015 o 23:51, Paweł Tomulik pisze:
> > Hi,
> >
> > W dniu 30.08.2015 o 18:40, William Blevins pisze:
> >> Did you try the patch as a short term solution?
> >>
> >
> > I would rather propose a germ of long-term solution:
> >
> >
> https://bitbucket.org/scons/scons/pull-requests/246/new-versioned-libraries-gnulink-and/diff
> >
> > The above PR reimplements the library versioning stuff. Currently
> > gnulink and cyglink (tested).
> >
> > Best regards!
> >
>
>
> is someone attempting to look at this new PR?
>
>
> https://bitbucket.org/scons/scons/pull-requests/247/new-versioned-libraries-gnulink-and/diff
>
>
> Regards!
> --
> Pawel Tomulik
> ___
> 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

Re: [Scons-dev] SCons Node ID

[Gary Oberbrunner]

On Fri, Sep 4, 2015 at 4:24 AM, anatoly techtonik 
wrote:

> On Fri, Sep 4, 2015 at 10:10 AM, Dirk Bächle  wrote:
>
>> On 04.09.2015 06:16, anatoly techtonik wrote:
>>
>>> I have another question about SCons. If I specify target explicitly, it
>>> ends up
>>> as str in BUILD_TARGETS and it is impossible to traverse. How do I
>>> transform it to Node if I don't know the type? I.e. how to lookup Node
>>> object
>>> by name?
>>>
>>>
>> you mean you explicitly specify a target "x" on the command line, but you
>> don't know whether it's a File or a Dir?
>> Can you come up with a short user scenario for this? What is it that
>> you're trying to accomplish?
>>
>
> The short user scenario - a person want to build wesnoth and executes
> `scons`. The output says that possible targets are "wesnoth" and
> "wesnothd". Because I don't have dependencies for "wesnoth", I specify
> "wesnothd" which ends up as str in BUILD_TARGETS and I can not traverse it.
>

Normally you just say e = Entry(str), which converts the string to an
Entry, which is a Node whose type is unknown.  At various points Entry
nodes are converted to their correct type once it can be deduced

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

Re: [Scons-dev] SCons webpage...

[Gary Oberbrunner]

Are you just talking about the fact that there are too many releases listed
under Latest News before you get to What is SCons and the quotes etc.?
I can fix that.

On Fri, Aug 7, 2015 at 3:11 AM, Dirk Bächle tshor...@gmx.de wrote:

 Hi there,

 I just noticed, that when I open the scons.org webpage in my browser it
 looks like the attached screenshot.
 Now imagine that you're someone who's interested in the project and opens
 the page the first time...it's bad UX because you don't see the vital info
 about the project itself.

 Can we do something about this? Now? ;)

 Second topic for today is, that I received a notification from
 printfection.com (where we have our SCons goodies store). They're going
 out of business, so the question from me to you is Should I bother to look
 for a replacement, or do we simply take the Shop out?. Additional info:
 two hands are enough to show the amount of sold items so far. ;)

 Best regards,

 Dirk

 ___
 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

Re: [Scons-dev] 2.3.6 out. Next up merging slots branch to default for stabilization and then release

[Gary Oberbrunner]

Congratulations all!  Looks great!

On Sat, Aug 1, 2015 at 12:06 AM, William Blevins wblevins...@gmail.com
wrote:

 Good news indeed!  Thanks for the release :)

 On Fri, Jul 31, 2015 at 11:35 PM, Bill Deegan b...@baddogconsulting.com
 wrote:

 Greetings,

 Now that 2.3.6 is out the door. Next step is to merge slots to default
 and bump the version string to 2.4.0.

 We'll do some stabilization and then push out a release.
 Hopefully without too much delay!

 Dirk - Please do the merge! Ready to let the world enjoy the benefits of
 all your hard work! (and I assume many other contributed along the way)

 -Bill

 ___
 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




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

Re: [Scons-dev] Cross-language support

[Gary Oberbrunner]

Hi Bill! I don't think it's compatibility breaking in that existing 
SConscripts will continue to work without change, but it _will_ require (cause) 
a rebuild in many cases, and we do usually pre-announce those changes and call 
them out in the release notes so people with huge projects don't get surprised. 
(Just to be clear, I'm not as averse to changes that cause rebuilds as Steven 
used to be -- it's sensible to avoid them when possible, but I don't think we 
need to avoid otherwise-sensible changes to avoid rebuilds every now  then.) 

-- Gary 

 From: Bill Deegan b...@baddogconsulting.com
 To: SCons developer list scons-dev@scons.org
 Sent: Tuesday, July 28, 2015 11:56:00 AM
 Subject: Re: [Scons-dev] Cross-language support

 Gary  Dirk,

 Thoughts on whether this change introduces compatibility breaking change?

 -Bill

 On Tue, Jul 28, 2015 at 7:24 AM, Bill Deegan  b...@baddogconsulting.com 
 wrote:

 William,

 It seems likely that since the change to scanning behavior will likely change
 many builds (as it's more accurate in tracing dependencies).

 As such I think we should pre-announce it.

 Is it safe to say this change breaks compatibility?
 (If you ran a build to completion without change, and reran it you'd get a 
 new
 build, switch to this change and it may rebuild some files)

 -Bill

 On Tue, Jul 28, 2015 at 12:16 AM, William Blevins  wblevins...@gmail.com 
 wrote:

 Once we have finalized the patch, so that the behavioral changes can be
 concretely defined, I will update those two files or should we do a 
 pre-release
 announcement like with the slots changes?

 V/R,
 William

 On Mon, Jul 27, 2015 at 8:34 PM, Bill Deegan  b...@baddogconsulting.com 
 wrote:

 William,

 I just got around to doing a thorough read of your pull request and added a
 couple comments.

 Notably c++ doe (in the standard) support and require usage of header 
 files with
 no extension:
 http://en.cppreference.com/w/cpp/header

 Another item is that since this is a change in functionality, 
 documentation will
 need updates.
 And we should probably put a section in the src/CHANGES.txt and 
 src/RELEASE.txt

 -Bill

 On Thu, Jul 9, 2015 at 7:18 AM, William Blevins  wblevins...@gmail.com  
 wrote:

 On Thu, Jul 9, 2015 at 5:56 AM, Russel Winder  rus...@winder.org.uk  
 wrote:

 Likely going off-topic…

 On Thu, 2015-07-09 at 00:20 -0400, William Blevins wrote:
  Thanks for responding everyone. I just wanted a heart beat so to
  speak,

 You could always play the start of Dark Side of the Moon ;-)

  since I wasn't sure how many members were watching the devs list.
  I'm not
  asking anyone to stop what they are doing, but a lot of what I have
  left is
  requirements related questions.

 Whilst I note every email, I mostly delete and move on due to not
 having enough time to properly contribute.

  I will hopefully still be able to work on SCons after early
  September, but
  I am going to be a little disorganized during the move and culture
  adjustment. I will be overseas for a year getting my MSc in Great
  Britain.

 Just to note that Great Britain is a geographic but not political
 entity, something the ISO committees handing out country codes chose to
 forget when trying to solve the UK/Ukraine problem.

 Where will you be studying and living when here?

 University of Sussex in Brighton; approximately Sept 2015 - Sept 2016.

  Also, I may not have my high-end workstation. I'm still debating
  whether or
  not I want to break it down and ship it.

 I guess this depends on cost. It always seems that countries shipping
 to UK pay about 0.5 or 0.3 the cost of shipping the same from the UK.
 Basically all companies (especially USA ones) charge far more in the UK
 for everything than they charge anywhere else in the world.

 Cost plus risk of it getting damaged. I generally build my own 
 workstations, so
 it's not like shipping X-U server form-factored machines. I will have to
 dismantle it prior to shipping. I'm tempted to ship it case less and buy
 another one in Britain because it'll be cheaper than shipping (probably).

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

 ___
 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

-- 
Gary 

Re: [Scons-dev] Cross-language support

[Gary Oberbrunner]

Yes, that's how we've done it in the past.  Sounds like doing it at the
same time as slots would be perfect.

-- Gary

On Tue, Jul 28, 2015 at 2:01 PM, Bill Deegan b...@baddogconsulting.com
wrote:

 Gary,

 For such a change we should bump the second digit?
 2.4?

 I agree we should not turn down a change because it will cause rebuilds
 where the past didn't as long as it is now more correct (which it should be
 with this change).
 Also agree we should be verbose in our notification of the impacts of the
 new change to avoid (as much as we can) surprises.


 -Bill


 On Tue, Jul 28, 2015 at 9:57 AM, Gary Oberbrunner ga...@oberbrunner.com
 wrote:

 Hi Bill!  I don't think it's compatibility breaking in that existing
 SConscripts will continue to work without change, but it _will_ require
 (cause) a rebuild in many cases, and we do usually pre-announce those
 changes and call them out in the release notes so people with huge projects
 don't get surprised.  (Just to be clear, I'm not as averse to changes that
 cause rebuilds as Steven used to be -- it's sensible to avoid them when
 possible, but I don't think we need to avoid otherwise-sensible changes to
 avoid rebuilds every now  then.)

 -- Gary


 --

 *From: *Bill Deegan b...@baddogconsulting.com
 *To: *SCons developer list scons-dev@scons.org
 *Sent: *Tuesday, July 28, 2015 11:56:00 AM
 *Subject: *Re: [Scons-dev] Cross-language support

 Gary  Dirk,

 Thoughts on whether this change introduces compatibility breaking change?

 -Bill

 On Tue, Jul 28, 2015 at 7:24 AM, Bill Deegan b...@baddogconsulting.com
 wrote:

 William,

 It seems likely that since the change to scanning behavior will likely
 change many builds (as it's more accurate in tracing dependencies).

 As such I think we should pre-announce it.

 Is it safe to say this change breaks compatibility?
 (If you ran a build to completion without change, and reran it you'd get
 a new build, switch to this change and it may rebuild some files)

 -Bill


 On Tue, Jul 28, 2015 at 12:16 AM, William Blevins wblevins...@gmail.com
  wrote:

 Once we have finalized the patch, so that the behavioral changes can be
 concretely defined, I will update those two files or should we do a
 pre-release announcement like with the slots changes?

 V/R,
 William

 On Mon, Jul 27, 2015 at 8:34 PM, Bill Deegan b...@baddogconsulting.com
  wrote:

 William,

 I just got around to doing a thorough read of your pull request and
 added a couple comments.

 Notably c++ doe (in the standard) support and require usage of header
 files with no extension:
 http://en.cppreference.com/w/cpp/header

 Another item is that since this is a change in functionality,
 documentation will need updates.
 And we should probably put a section in the src/CHANGES.txt and
 src/RELEASE.txt

 -Bill

 On Thu, Jul 9, 2015 at 7:18 AM, William Blevins wblevins...@gmail.com
  wrote:



 On Thu, Jul 9, 2015 at 5:56 AM, Russel Winder rus...@winder.org.uk
 wrote:

 Likely going off-topic…

 On Thu, 2015-07-09 at 00:20 -0400, William Blevins wrote:
  Thanks for responding everyone.  I just wanted a heart beat so to
  speak,

 You could always play the start of Dark Side of the Moon ;-)

  since I wasn't sure how many members were watching the devs list.
   I'm not
  asking anyone to stop what they are doing, but a lot of what I have
  left is
  requirements related questions.

 Whilst I note every email, I mostly delete and move on due to not
 having enough time to properly contribute.

  I will hopefully still be able to work on SCons after early
  September, but
  I am going to be a little disorganized during the move and culture
  adjustment.  I will be overseas for a year getting my MSc in Great
  Britain.

 Just to note that Great Britain is a geographic but not political
 entity, something the ISO committees handing out country codes chose
 to
 forget when trying to solve the UK/Ukraine problem.

 Where will you be studying and living when here?

 University of Sussex in Brighton; approximately Sept 2015 - Sept 2016.



  Also, I may not have my high-end workstation. I'm still debating
  whether or
  not I want to break it down and ship it.

 I guess this depends on cost. It always seems that countries shipping
 to UK pay about 0.5 or 0.3 the cost of shipping the same from the UK.
 Basically all companies (especially USA ones) charge far more in the
 UK
 for everything than they charge anywhere else in the world.

 Cost plus risk of it getting damaged.  I generally build my own
 workstations, so it's not like shipping X-U server form-factored 
 machines.
 I will have to dismantle it prior to shipping.  I'm tempted to ship it 
 case
 less and buy another one in Britain because it'll be cheaper than 
 shipping
 (probably).



 --
 Russel.

 =
 Dr Russel Winder  t: +44 20 7585 2200   voip:
 sip:russel.win...@ekiga.net
 41 Buckmaster Roadm: +44

Re: [Scons-dev] Cross-language support

[Gary Oberbrunner]

I'm here too -- more or less.  Having worked a little bit with you on the
original version of this, I'd very much like to see it get in.  Your #2 is
fine I think.  #1 is complicated.  #3 I don't remember the details, will
have to review again.

On Wed, Jul 8, 2015 at 7:59 PM, Bill Deegan b...@baddogconsulting.com
wrote:

 William,

 Nothing that you've written to this email can be properly responded to
 with a brief look a the code or issues involved.
 So first let me say thank you for your persistence on working on this
 issue and looking deeper into SCons than most.

 For myself I've been training for a half IronMan which has eaten up the
 bulk of my alotted open source participation time.
 Luckily that event is Sunday and so next week (assuming I survive ;) I'll
 have time to do a deep dig and give thoughtful comments.

 -Bill


 On Wed, Jul 8, 2015 at 7:23 PM, William Blevins wblevins...@gmail.com
 wrote:

 Yeah.  The last few times I used the Dev list no one responded, so I just
 wanted to make sure someone was out there somewhere :)

 On Wed, Jul 8, 2015 at 7:09 PM, Jason Kenny dragon...@live.com wrote:

   I have.. I plan to respond soon [image: Smile]

 Jason

  *From:* William Blevins wblevins...@gmail.com
 *Sent:* Wednesday, July 8, 2015 5:59 PM
 *To:* SCons developer list scons-dev@scons.org
 *Subject:* Re: [Scons-dev] Cross-language support

   Is there anyone on this mailing list?

 I just want to make sure someone *might* have even read this email.

 V/R,
 William

 On Mon, Jul 6, 2015 at 8:38 PM, William Blevins wblevins...@gmail.com
 wrote:

 Team,

 Due to some upcoming real life events, I would like to wrap up the
 cross-language scanner support materials by Sept 1, 2015.  I was working
 with Jason recently, but he got side-tracked with his own real life events.

 It is mostly complete.  There are really only 3 remaining items that I
 am aware (might be some other languages I cannot test). Details available
 in the patch discussion:
 https://bitbucket.org/scons/scons/pull-request/237/issue-2264-cross-language-scanner-support/diff

 TL;DR
 1. Recursive install scanning.  This one is somewhat involved, but
 could be easy if we decide to simply disable scanner recursion of the
 install builder.  Not sure if this is an option.
 2. Is the Ignore() for QT satisfactory?  I assume yes.
 3. Is enforcing valid keys satisfactory?  I can return the input if not
 which will be similar to past behavior.

 V/R,
 William



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




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

Re: [Scons-dev] SCons release version tagging question

[Gary Oberbrunner]

IMHO, version number alone is fine.  Probably the usual process which has
the release on its own branch is why this normally works.  But it is
time-consuming so if you want to simplify I'm all for it.

On Wed, Jun 17, 2015 at 7:40 PM, Bill Deegan b...@baddogconsulting.com
wrote:

 Greetings,

 I'm fixing some logic in SCons's own SConstruct which sets the revision
 number.
 Currently is has the revision #, changeset has, branch, and whether it's
 modified.

 I also notice that 2.3.4 didn't have this info, so I'm guessing it
 bootstrap.py was passed the revision id

 (venv)WilliamsMacBook:scons-2.3.4 bdbaddog$ scons --version
 SCons by Steven Knight et al.:
 script: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu
 engine: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu
 engine path: ['/Users/bdbaddog/tmp/venv/lib/scons-2.3.4/SCons']
 Copyright (c) 2001 - 2014 The SCons Foundation

 Should this be the practice going forward?
 Or is there value in having 2.3.5, revision #3252, changeset 385adb84f
 for example?

 -Bill

 ___
 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

Re: [Scons-dev] SCons release version tagging question

[Gary Oberbrunner]

Pretty sure yes.  All that is checked in on each release branch so you can
see it.

On Wed, Jun 17, 2015 at 8:40 PM, Bill Deegan b...@baddogconsulting.com
wrote:

 Gary,

 Were you calling bootstrap.py REVISION=2.3.4 then?

 -Bill

 On Wed, Jun 17, 2015 at 4:56 PM, Gary Oberbrunner ga...@oberbrunner.com
 wrote:

 IMHO, version number alone is fine.  Probably the usual process which has
 the release on its own branch is why this normally works.  But it is
 time-consuming so if you want to simplify I'm all for it.

 On Wed, Jun 17, 2015 at 7:40 PM, Bill Deegan b...@baddogconsulting.com
 wrote:

 Greetings,

 I'm fixing some logic in SCons's own SConstruct which sets the revision
 number.
 Currently is has the revision #, changeset has, branch, and whether it's
 modified.

 I also notice that 2.3.4 didn't have this info, so I'm guessing it
 bootstrap.py was passed the revision id

 (venv)WilliamsMacBook:scons-2.3.4 bdbaddog$ scons --version
 SCons by Steven Knight et al.:
 script: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu
 engine: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu
 engine path: ['/Users/bdbaddog/tmp/venv/lib/scons-2.3.4/SCons']
 Copyright (c) 2001 - 2014 The SCons Foundation

 Should this be the practice going forward?
 Or is there value in having 2.3.5, revision #3252, changeset 385adb84f
 for example?

 -Bill

 ___
 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




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

Re: [Scons-dev] Wiki down again

[Gary Oberbrunner]

I don't have the time/energy/desire to continue working on a system that is
unsustainable for us, and seems to be getting more so.  If you'd like to
push on it, feel free.

-- Gary

On Thu, Jun 4, 2015 at 8:25 AM, anatoly techtonik techto...@gmail.com
wrote:

 Can they be more accurate where exactly the vulnerability is? IIRC we
 have 1.9.8 version (latest) installed, so if there is an exploit, the
 upstream should be notified too.

 On Thu, Jun 4, 2015 at 1:05 PM, Gary Oberbrunner ga...@oberbrunner.com
 wrote:
  Pair said it was an exploited attack on the wiki script itself this time,
  which is worse.  Usually it's just excessive load due to spammers
 trying
  to create pages, which is basically a DoS.
 
  On Thu, Jun 4, 2015 at 3:13 AM, anatoly techtonik techto...@gmail.com
  wrote:
 
  On Wed, Jun 3, 2015 at 7:56 PM, William Blevins wblevins...@gmail.com
  wrote:
   Wiki is down again due to invalid permissions.  I assume more DOS
   attacks.
   We should consider changing providers or something...
 
  First, let's have some proof that it is DOS attack. Do you have access
  to logs and
  statistics?
 
  --
  anatoly t.
  ___
  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
 



 --
 anatoly t.
 ___
 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

Re: [Scons-dev] Wiki down again

[Gary Oberbrunner]

Yes.  Grr.  This one is even worse, apparently there's an exploited
vulnerability in the wiki script. :-(

We have all the moin content; if anyone can help translate it to _anything_
so we can get it live on an AWS instance or whatever (just a git-backed
wiki or anything) that would be very helpful.

On Wed, Jun 3, 2015 at 12:56 PM, William Blevins wblevins...@gmail.com
wrote:

 Wiki is down again due to invalid permissions.  I assume more DOS
 attacks.  We should consider changing providers or something...

 V/R,
 William

 ___
 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

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

[Gary Oberbrunner]

On Wed, Jun 3, 2015 at 6:54 AM, anatoly techtonik techto...@gmail.com
wrote:

 But I have plenty of other files in current directory. Why those are
 not included?

 At the end of reading the SConstruct, i.e. before the build phase begins,
SCons only creates Nodes for files it has been told about.  I think if you
were to try this at the end of the build phase  (register a function with
python atexit.register for instance) I think the other files would be
there.  Though they might be only if . is used as a source, I'm not sure.


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

Re: [Scons-dev] Merge PR #235 before release

[Gary Oberbrunner]

If you're interested in this problem, I suggest reading
https://docs.python.org/2/howto/unicode.html which has all the details
(including how to ignore decode errors), and of course check out the
python3 branch of scons where a lot of unicode handling has been done (but
much is still left to do iirc).  I don't think pretending strings are in
the cp437 encoding is a particularly good plan. ISO 8859-1 or Windows
CP1252 would probably give better results in some cases but you still need
to ignore errors in the decode.  And of course if the string actually is
utf-8 with non-ascii chars, either of these encodings will return a string
of the wrong length, not just wrong characters; and re-encoding it for
output or storage will completely mangle it.

Of course we _can_ know the encoding of the filenames in the filesystem,
that's what sys.getfilesystemencoding() is for (see the unicode link
above). Reading file contents and handling stdout/stderr from SCons
subprocesses is much more of a challenge.


On Thu, May 28, 2015 at 3:28 AM, anatoly techtonik techto...@gmail.com
wrote:

 I found a way to convert any binary string to Unicode without crashing -
 http://stackoverflow.com/a/27527728/239247 That would correctly
 convert all `ascii` characters (and will probably make it possible to use
 ANSI graphics if unicode font supports that), but it will not work for
 other
 utf-8 characters.

 Python 3 adds some surrogateescape, but that is not present in Python 2.

 http://stackoverflow.com/questions/19649463/how-to-do-surrogateescape-in-python2
 I don't know why they called it surrogate - it is a freaky word.

 On Wed, May 27, 2015 at 4:33 PM, Kenny, Jason L jason.l.ke...@intel.com
 wrote:
  I would agree with this.
 
 
 
  In general the OS today store file data ( ie the file system data not the
  data in the file) in Unicode ( be it utf-16 or utf-8). On Linux this is
 not
  always the case it could be big5 or some other locale encoding.  On Linux
  there are means to see what the “native” encoding is to use it.
 
 
 
  I should note that the idea of converting binary to Unicode does not
 really
  exist. The point of a binary string to is to hold random data ( ie like a
  double in the raw form 64-bit vs the dec values of 1.2385). One can
 assume
  that it is a certain code page encoding and convert from that. And like I
  stated above there are api to see what the locale code page encoding is
 and
  that can be used to convert the code to the local ANSI/OEM encoding.
 This is
  different from a binary string.
 
 
 
  Jason
 
 
 
 
 
 
 
  From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Gary
  Oberbrunner
  Sent: Wednesday, May 27, 2015 7:43 AM
  To: SCons developer list
  Subject: Re: [Scons-dev] Merge PR #235 before release
 
 
 
 
 
  On Wed, May 27, 2015 at 6:52 AM, anatoly techtonik techto...@gmail.com
  wrote:
 
  What I need is a bulletproof way to convert from anything to unicode.
 This
  requires some kind of escaping to go forward and back. Some helper
  methods like u2b() (unicode to binary) and b2u(). I am quite surprised
 that
  so far I found nothing for this simple case.
 
 
  That's because in general the encoding of the binary string is unknown.
  Is it ascii, utf-8, Windows CP-1252, shift-JIS, or something else?  You
  can't decode such a string to Unicode without knowing the encoding.
 Check
  out the python-3 branch where we've been working through some of those
  issues.  Your u2b is easy if you assume you want the binary to be utf-8
  encoded, which is normally safe; this conversion is guaranteed to work.
  Your b2u is not so easy.  You can't just assume utf-8 as you might
 think; if
  the string has invalid utf-8 bytes it'll raise an error or generate dummy
  chars depending on the args you pass to str.decode().  At least it'll get
  mangled if it's in a different encoding than you expect.
 
 
 
  --
 
  Gary
 
 
  ___
  Scons-dev mailing list
  Scons-dev@scons.org
  https://pairlist2.pair.net/mailman/listinfo/scons-dev
 



 --
 anatoly t.
 ___
 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

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

[Gary Oberbrunner]

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

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

[Gary Oberbrunner]

On Wed, May 20, 2015 at 11:50 AM, Alexandre Feblot alexan...@feblot.fr
wrote:

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


I'm not 100% certain, but I believe calling node.children()  can invoke
scanners and other things that should normally be done in particular orders
by the build process rather than during the SConstruct-reading phase.  Of
course it is likely to be more complete than node.sources.


-- 
Gary
___
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

[Gary Oberbrunner]

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

 If so, then that means that every target should
 be a filesystem object?

 What is target then? If it is a name, how a lookup if made to locate it in
 FS tree?


Every target (and source, and intermediate) is a Node.  The Node object
knows everything about that node, including name, path, parent, sources,
builder, build state, and so on.  There is no lookup in the sense you're
talking about.

If you want to get the Node object corresponding to a filename, just call
f=File(myfile) or f=File(/a/b/c/myfile) etc.

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

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

[Gary Oberbrunner]

SCons Install just copies files (and in this case makes symlinks).
Building installers is a whole different thing.  SCons can do it, but
Install isn't what you're looking for.

On Tue, May 19, 2015 at 8:51 AM, anatoly techtonik techto...@gmail.com
wrote:

 On Tue, May 19, 2015 at 3:29 AM, William Blevins wblevins...@gmail.com
 wrote:
  Anatoly,
 
   I've sent a pull request with the changes:
   https://github.com/techtonik/RHVoice/pull/1
 
  Thanks. 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?
 
 
  Here is my understanding of linux standards for shared libraries:
 
  Example:
  thing.so - thing.so.1
  thing.so.1 - thing.so.1.2.3
  thing.so.1.2.3 (the real file)
 
  GNU linkers (and others) embed shared library information into the final
  product in the form thing.so.1, so that the library can undergo patch
  updates (EG. 1.2.3 - 1.2.4) without requiring the application to be
  recompiled.

 That make it clear. Thanks.

 The only question is the Install stuff. The operating system knows better
 where to install things, no? It creates a package registry and tracks all
 the
 files. Is SCons Install just a development hack?
 ___
 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

Re: [Scons-dev] SCons and Python 3.0

[Gary Oberbrunner]

On Wed, Feb 25, 2015 at 3:31 PM, Russel Winder rus...@winder.org.uk wrote:

 On Wed, 2015-02-25 at 21:10 +0100, Dirk Bächle wrote:
 […]
 
  you're aware of the fact that we already have a branch for this
 (python3-port)?

 It is though now seriously out of date, and not being worked on by
 people doing things, just talked about by people like me hoping things.

 It shouldn't be all that out of date.  I merged default branch into it
last year; there haven't been huge changes since then.  Doing another merge
into it to keep it current should not be a big task. The idea is that at
some point (not all that far from now) it should get finished (so the tests
pass) and merged back into the default branch, then we have a working
2.7/3.x codebase.

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

Re: [Scons-dev] mimetypes: adding mimetype for scons scripts

[Gary Oberbrunner]

On Wed, Jan 21, 2015 at 8:05 AM, Carnë Draug carandraug+...@gmail.com
wrote:

 ...
  scons [1] is a build system and I was thinking of adding it to
  shared-mime-info.  Its files are very simple to identify, they are
  always named SConstruct or SConscript.  These files are also valid
  python scripts.
 
  Should shared-mime-info identify them (I can submit a git patch, no
  problem)


This seems like an easy thing to add, with some possible upside and no
downside.  So why not, I say. Carnë, I think it would be better for you to
add it to shared-mime-info; SCons could do it but (a) it would be more
complex, and (b) it wouldn't identify SConstructs when SCons isn't
installed.

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

Re: [Scons-dev] mimetypes: adding mimetype for scons scripts

[Gary Oberbrunner]

On Wed, Jan 21, 2015 at 8:28 AM, Carnë Draug carandraug+...@gmail.com
wrote:


 what if the magic uses the following globs for filenames SConstruct,
 SConscript, and SConscript.* ?


These seem good to me.  I think a few people may use *.scons, but that's
probably not popular enough to deserve going into shared-mime-info.

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

Re: [Scons-dev] PRs marked as declined

[Gary Oberbrunner]

On Sun, Jan 11, 2015 at 9:12 AM, anatoly techtonik techto...@gmail.com
wrote:

 On Sun, Jan 11, 2015 at 4:25 PM, Gary Oberbrunner ga...@oberbrunner.com
 wrote:
  Our usual problem is we merge a PR manually, but then bitbucket doesn't
  recognize the change for whatever reason, and there's no way to manually
  accept a PR (there's a bitbucket issue for this) so we have to decline
 it
  and say it was really accepted.  I don't think we've seen truly
 spontaneous
  declines.

 Do you mean that Merge button doesn't work after the manual merge?

 Correct -- when I tried it a long time ago it created an extra merge
commit and messed things up.

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

Re: [Scons-dev] Parts checkout URL needs authorization

[Gary Oberbrunner]

This is still true.  Just wanted to download the latest Parts via svn but
as Anatoly says, it requires authentication.

-- Gary

On Fri, Dec 26, 2014 at 4:56 AM, anatoly techtonik techto...@gmail.com
wrote:

 Christmas!

 Jason, I thought you need to know that URL for parts requires
 authentication:
 On this page:
 http://parts.tigris.org/servlets/ProjectProcess?pageID=JlBX2F
 The URL:
 http://parts.tigris.org/svn/parts/tags/parts_0.10.8

 Seems like a major issue to me.
 --
 anatoly t.
 ___
 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

Re: [Scons-dev] Clang support

[Gary Oberbrunner]

On Mon, Jan 5, 2015 at 7:48 AM, Paweł Tomulik ptomu...@meil.pw.edu.pl
wrote:

  ...
 I have a project where I just set construction variables CC=clang and
 CXX=clang++ and it works well


That's more or less what we do too (in addition to some clang-specific
flags we need).  Seems to work fine.

It'll be much easier to support clang with the new toolchain stuff I'm
working on (slowly, but r0).

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

Re: [Scons-dev] Clang support

[Gary Oberbrunner]

On Mon, Jan 5, 2015 at 7:02 PM, Paweł Tomulik ptomu...@meil.pw.edu.pl
wrote:

 Looks like SCons is missing a tool preference system, where each user
 (developer, not end user) could easily re-define by its own the preferred
 order of compiler toolchains. The same applies to other tools. Don't worry,
 there will always be room for discussion, for example what should be the
 default preference order :)


This will be (much) more configurable at some point.  There will be chains
of tools, selectable and overridable and auto-detectable in various ways.
I'm working on it.

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

Re: [Scons-dev] RELEASE.txt bug

[Gary Oberbrunner]

2014-12-23 8:39 GMT-05:00 anatoly techtonik techto...@gmail.com:

 http://www.scons.org/RELEASE.txt

 RELEASE 2.3.4 - Mon, 27 Sep 2014 12:50:35 -0400

   Please consult the RELEASE.txt file for a summary of changes...

 ???


That sure looks like a bug. :-)

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

Re: [Scons-dev] Build server for Windows

[Gary Oberbrunner]

Nice!  Can we integrate that into our build process?

On Thu, Dec 18, 2014 at 6:33 AM, anatoly techtonik techto...@gmail.com
wrote:

 Hi,

 Found a Windows alternative to drone.io - check this out:
 https://ci.appveyor.com/project/anatolytechtonik/scons/build/2-default

 --
 anatoly t.
 ___
 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

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

[Gary Oberbrunner]

On Sat, Dec 13, 2014 at 12:25 PM, Dirk Bächle tshor...@gmx.de wrote:

 On 13.12.2014 17:53, Bill Deegan wrote:

 Can find search on bitbucket version, but it's there on github.

  Good point, that would speak for github then..since bitbucket isn't too
 interested in searching and hierarchies:

 https://groups.google.com/forum/#!topic/bitbucket-users/R0ZJrWhhMTo
 http://stackoverflow.com/questions/3050545/bitbucket-
 wiki-create-a-heirarchy-structure

 But even github doesn't do a full text search, it can only find page
 titles. :(


On the other hand, bitbucket seems OK with /-separated hierarchical pages,
where github doesn't seem to.  And we have many of those.

Some of the pages (e.g.
https://bitbucket.org/scons/scons/wiki/GSoC2012/Ideas) have been cut short
by the converter too. I'll keep poking at it.  You can still see the moin
pages at least in bitbucket;
https://bytebucket.org/scons/scons/wiki/GSoC2012/Ideas.moin

-- 
Gary
___
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?

[Gary Oberbrunner]

On Sat, Dec 13, 2014 at 3:54 PM, Bill Deegan b...@baddogconsulting.com
wrote:

 All,

 I think two items for wiki are must have:
 1) full text searchable from the wiki
 2) index able by google and others.

 I'm pretty sure neither bitbucket nor github has both. (Though I suppose 1
 would come with 2)
 As for giving specific contributors unfettered write access. I think we
 could just give them write access to a given repo. (which is where the wiki
 is).
 No such access control exists for a project's wiki under bitbucket.

 Assuming I have a host to put moin on, does anyone know how to configure
 it to minimize the load it causes? Can you put a caching proxy in front of
 it?


I'm not certain what has caused our load spikes at pair, but I think some
kind of rate-limiting of requests from a single IP would help a lot. I
don't think moin's page rendering is very expensive.  (Moin does some
caching anyway: http://moinmo.in/MoinCaching)

If you can re-host our wiki somewhere, that might be the best solution.  I
agree, neither of the current proposals really do it.

-- 
Gary
___
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?

[Gary Oberbrunner]

I would like to find a system that has some kind of online
editor/previewer, rather than a pure clone/edit/push/pull-request system
(whether it's git or hg), because sometimes you want to see how your markup
will actually look on the site before pushing it.  (Dirk, I think that
would also help the occasional contributor overhead you're concerned
about.)  I do think something hg or git-based would be preferable.  And
yes, we have to move it off our current hosting provider because DoS
attacks on our MoinMoin wiki bring the shared server to its knees on a
somewhat regular basis.  And I'm not ready to be sysadmin of another amazon
micro instance, so we need a hosted solution.

Anyway, I have the existing wiki mostly converted from moin to markdown
(github flavor, but I could redo it as a different flavor depending on what
we choose) with only a few hand edits necessary.  Some things like the
Bug() macro won't translate, but I think we can live without that.  I
didn't find any decent tools to convert from moin to rst, so I think going
with a markdown solution would be easier than rst at this point, though I
think pandoc can convert between markdown and rst, so if needed we can do
that -- not sure how lossy that conversion would be.

So that's the state of the wiki world at this point.  I'll try to make
progress over the weekend but am not sold on a particular solution;
bitbucket seems like the easiest path right now but I'm open to other
possibilities if they meet the above criteria.


On Fri, Dec 12, 2014 at 4:12 AM, anatoly techtonik techto...@gmail.com
wrote:

 I think we just need hosting with better protection.

 On Fri, Dec 12, 2014 at 3:09 AM, Dirk Bächle tshor...@gmx.de wrote:
  Bill,
 
 
  On 12.12.2014 00:52, Bill Deegan wrote:
 
  I'm thinking a hg repo and some sort of ci to process it when new changes
  come in.
  Or use readthedocs.org (It has integration with bitbucket for such
 already)
 
  That way users and do pull requests and also the webserver only has to
  handle serving static pages.
 
  Is it reasonable to expect that users who wanted to contribute to
 wiki-like
  content could handle mercurial?
 
  it's probably not so much about hg (or any other tool, for that matter),
 but
  about the workflow that's required for getting one's changes in. To me it
  feels like we're moving away from a more scratchpad-like medium, to
 static
  pages. That would be okay if we had several authors and technical writers
  that could create lots of pages with content. But this would mean that we
  provide all the information, and we are responsible for keeping things
  alive.
  If that's what we want, fine.
  It more or less boils down to the question: Do we want a Wiki (static
 pages)
  for us, or for our users?
 
  Just some late night thoughts, to fuel the discussion...
 
  Regards,
 
  Dirk
 
 
  ___
  Scons-dev mailing list
  Scons-dev@scons.org
  https://pairlist2.pair.net/mailman/listinfo/scons-dev
 



 --
 anatoly t.
 ___
 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

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

[Gary Oberbrunner]

On Fri, Dec 12, 2014 at 11:16 AM, Dirk Bächle tshor...@gmx.de wrote:

 Gary,

 On 12.12.2014 15:00, Gary Oberbrunner wrote:

 I would like to find a system that has some kind of online
 editor/previewer, rather than a pure clone/edit/push/pull-request system
 (whether it's git or hg), because sometimes you want to see how your markup
 will actually look on the site before pushing it.  (Dirk, I think that
 would also help the occasional contributor overhead you're concerned
 about.)  I do think something hg or git-based would be preferable.

 sounds acceptable. What I'm mainly after is that a user can queue his
 changes...and then forget about them. So he doesn't have to cycle through
 all kinds of review steps, or answer further inquiries. That might put
 people off...
 It should be edit, save/commit...done.

 And yes, we have to move it off our current hosting provider because DoS
 attacks on our MoinMoin wiki bring the shared server to its knees on a
 somewhat regular basis.  And I'm not ready to be sysadmin of another amazon
 micro instance, so we need a hosted solution.

  Do we have admin access to the host where our website is running on?
 What is it exactly, apached? I just stumbled over this module

 http://www.techrepublic.com/blog/smb-technologist/secure-
 your-apache-server-from-ddos-slowloris-and-dns-injection-attacks/


No, sadly we don't.   Just .htaccess.  And I don't think our problems stem
from those kinds of things, though perhaps the first one would help, I
don't know.  A lot of it is fake account creation attempts and other probes
based on knowing it's a moinmoin wiki.


 , not sure if it could really help.

  Anyway, I have the existing wiki mostly converted from moin to markdown
 (github flavor, but I could redo it as a different flavor depending on what
 we choose) with only a few hand edits necessary.  Some things like the
 Bug() macro won't translate, but I think we can live without that.  I
 didn't find any decent tools to convert from moin to rst, so I think going
 with a markdown solution would be easier than rst at this point, though I
 think pandoc can convert between markdown and rst, so if needed we can do
 that -- not sure how lossy that conversion would be.

 There is also Creole ( http://en.wikipedia.org/wiki/Creole_(markup) ),
 which is supported by Bitbucket. I have no personal experience with it, but
 it seems to be designed for exactly this purpose of migrating from one Wiki
 to another


 I didn't find any translators from moinmoin to creole.  I don't think
pandoc can go from markdown (what I have now) to creole yet.  BItbucket
also supports markdown though, so if we want to do that it would be easy
(technically).  Some folks in this discussion seemed to think it wasn't
great, I don't know.  Since I have the markdown pages (or will by the
weekend), I can try pushing up a repo as a bb wiki and we can see how we
like it.

It would be a little odd to have our code at bitbucket and our wiki at
github, but if github's wiki engine/editor is way better, I'd consider it.
After all our wiki has been a separate thing for years already.

-- 
Gary
___
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?

[Gary Oberbrunner]

On Fri, Dec 12, 2014 at 1:44 PM, yegle cnye...@gmail.com wrote:

 On Fri, Dec 12, 2014 at 10:32 AM, Gary Oberbrunner
 ga...@oberbrunner.com wrote:
  You're thinking I want to move _everything_ to github I bet.  Actually,
 no.
  I do like git better than mercurial, it's true; but bitbucket seems to
 have
  fine git support these days so I'm agnostic on that. I really just want
 to
  get the wiki back up soon, and not have to think about it anymore for a
  while :-).  If someone proposes some other code-oriented wiki site I'd be
  just as happy to use that for the wiki.

 How about host the markdown files in github, and publish them using
 Github Pages?


It's possible.  There's no online editor there, however, which I think will
limit the contributions to the wiki.
-- 
Gary
___
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?

[Gary Oberbrunner]

On Fri, Dec 12, 2014 at 2:14 PM, yegle cnye...@gmail.com wrote:

 On Fri, Dec 12, 2014 at 11:08 AM, Gary Oberbrunner
 ga...@oberbrunner.com wrote:
  It's possible.  There's no online editor there, however, which I think
 will
  limit the contributions to the wiki.

 Yes there is, for every file in github, you can click on the small
 edit button on the up right corner, which will bring you to something
 like https://github.com/golang/go/edit/master/README.md Github will
 automatically fork that repo for you and submit a PR on your behave.


Aha, I didn't know that!  Nice.  The previewer looks good, and even marks
your changes in the margin.

(A little odd that it has to fork the repo for you, but it kind of makes
sense.)

-- 
Gary
___
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?

[Gary Oberbrunner]

On Fri, Dec 12, 2014 at 5:34 PM, Bill Deegan b...@baddogconsulting.com
wrote:

 You can pair that with this javascript/jquery based browser based wiki..
 http://dynalon.github.io/mdwiki/#!index.md

 -Bill


Interesting... the point of that is to provide theming and richer content I
take it?  It doesn't provide an editor, but maybe the built-in github
editor would continue to work.

(Their FAQ does say it's hard to make the pages crawlable, and I do think
that's important.)


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

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

[Gary Oberbrunner]

On Sat, Dec 6, 2014 at 4:35 AM, Shreedhar Manek shreedharma...@gmail.com
wrote:


 I change the integer the equivalent string in chmod.py (eg. 0444
 to S_IRWXU and S_IRWXG and S_IRWXO) but there is problem ahead into the
 program and the test fails at this point -


 Watch out, 0444 is not the same as  S_IRWXU and S_IRWXG and S_IRWXO,
 which would be  because of the ands. 0444 is S_IRUSR or S_IRGRP or
 S_IROTH.



 Ah, of course. Thanks!



 s = S_IMODE(os.stat(test.workpath('f1'))[ST_MODE])
 test.fail_test(s != 0444)

 What do I do about this?


 How does it fail?  What is the value of s at that point?


 The value of s at that point in decimal is 256. I cannot figure why
 though, as the only change that I've made is switching 0444 by S_IRUSR or
 S_IRGRP or S_IROTH.

 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

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

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

[Gary Oberbrunner]

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

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

[Gary Oberbrunner]

On Sat, Dec 6, 2014 at 1:03 PM, alexandre.feb...@gmail.com wrote:

 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)


Good detective work!  The second is a bit more modern in style, but they
both seem workable.

-- Gary




 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




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

Re: [Scons-dev] Switching the Node class to __slots__

[Gary Oberbrunner]

It might; that's why we want to introduce it gently, to see what the
impact will be.

Note that people currently setting arbitrary properties directly on the
Node can use Node.attributes for this (and could/should be doing so
already).

On Fri, Dec 5, 2014 at 5:12 AM, anatoly techtonik techto...@gmail.com
wrote:

 On Tue, Nov 25, 2014 at 11:37 PM, Dirk Bächle tshor...@gmx.de wrote:
  switching the Node class to __slots_

 Are there any SCons plugins that extend Node with their own
 properties? Won't it be the major compatibility break?
 --
 anatoly t.
 ___
 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

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

[Gary Oberbrunner]

On Thu, Dec 4, 2014 at 4:39 PM, Shreedhar Manek shreedharma...@gmail.com
wrote:

 I need help with adapting tests.


Hi!


 I change the integer the equivalent string in chmod.py (eg. 0444
 to S_IRWXU and S_IRWXG and S_IRWXO) but there is problem ahead into the
 program and the test fails at this point -


Watch out, 0444 is not the same as  S_IRWXU and S_IRWXG and S_IRWXO, which
would be  because of the ands. 0444 is S_IRUSR or S_IRGRP or S_IROTH.


 s = S_IMODE(os.stat(test.workpath('f1'))[ST_MODE])
 test.fail_test(s != 0444)

 What do I do about this?


How does it fail?  What is the value of s at that point?

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

Re: [Scons-dev] [Scons-users] Man page problems with installing latest scons from Bitbucket

[Gary Oberbrunner]

On Sun, Nov 16, 2014 at 3:01 PM, Bill Deegan b...@baddogconsulting.com wrote:
 Dirk,

 Are they available from another apt-repo? Maybe one of the unsafe ones?
 (Where they stick blobs)

I googled around for quite a while; I didn't find where or why they
were removed but also didn't find any alternative (other than the
Windows python setuptools).

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

Re: [Scons-dev] [Scons-users] Man page problems with installing latest scons from Bitbucket

[Gary Oberbrunner]

Just one more thing on this, redirecting to scons-dev.  I just updated
my SCons build VM to Trusty (14.04) from Precise (12.04), and I get
the same error Michael was seeing when trying to do a full packaging
build of SCons:
  error: [Errno 2] No such file or directory:
'/usr/lib/python2.7/distutils/command/wininst-6.0.exe',
/usr/lib/python2.7/distutils/command/wininst-6.0.exe not included in
the Debian packages.

It seems the wininst-*.exe files have been removed from the
python2.7-dev package in 14.04, although they were there in 12.04.  I
worked around it by copying them from a Windows machine with python
distutils.  Grr.

-- Gary


On Fri, Oct 24, 2014 at 7:32 PM, Michael Jarvis mjarvis.tx...@gmail.com wrote:
 Thanks, Gary, I get it now. :-)

 I have it installed successfully, and if I get time, I'll see what I can do
 to help out with some of the coding.


 On Fri, Oct 24, 2014 at 5:42 PM, Gary Oberbrunner ga...@oberbrunner.com
 wrote:

 On Fri, Oct 24, 2014 at 6:25 PM, Michael Jarvis mjarvis.tx...@gmail.com
 wrote:
  Thanks, initially I'd like to get it installed, but I will probably want
  to
  hack on it as well.

 OK, just do this then:

   python setup.py install

 and you'll be good to go.

  Installing fop solved my initial error, but now it's complaining
  because
  it's looking for Windows:

 As I said, if you really want to build your own installer packages (we
 build for Windows as well as other OSes) you'll need various
 additional dependencies.  But you _really_ don't need to do that.
 Only the release team does.
 ...
  It would be nice if there was a quick description of how to override
  them.
  Do I need to actually modify the SConstruct file in my copy of the
  repository, or can I just set environment variables?

 Neither.  Just don't try to do what you're doing.  :-)

  I'm still learning the tool, so it may be that I just haven't read the
  documentation well enough.

 --
 Gary
 ___
 Scons-users mailing list
 scons-us...@scons.org
 https://pairlist4.pair.net/mailman/listinfo/scons-users




 --
 Michael Jarvis
 McKinney, TX USA
 http://about.me/michael.a.jarvis

 ___
 Scons-users mailing list
 scons-us...@scons.org
 https://pairlist4.pair.net/mailman/listinfo/scons-users




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

Re: [Scons-dev] Likely bug - installing side effect files

[Gary Oberbrunner]

On Mon, Nov 3, 2014 at 8:44 AM, Ben Golding ben.gold...@synopsys.com wrote:
 Nevertheless, what effect does this marking of the side effect file 
 actually have during the build? What can I usefully do with the object 
 returned by SideEffect()?

 Does it have an effect during the parallel build? (like a mutex, restricting 
 that only one builder instance can run concurrently if they share the same 
 hard-coded filename)

Yes, that's exactly what it does -- only one builder that produces a
given side effect can run at a time.  It also prevents these files
from being deleted in some cases before a builder runs, at least
that's what I remember.

There's probably a place in Taskmaster (maybe task_prepare or
something like that) that could check for a side-effect node being
used as a source and emit a warning.

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

Re: [Scons-dev] Likely bug - installing side effect files

[Gary Oberbrunner]

On Fri, Oct 31, 2014 at 2:55 PM, Dirk Bächle tshor...@gmx.de wrote:
 I don't think there is anything to fix here...and it's no bug for me either.
 Please read the man page for the definition
 of a SideEffect, and when it should be used. My understanding is, that in
 your case the conditions do not apply...so you should rather define an
 Emitter (see http://www.scons.org/wiki/ToolsForFools for example) that adds
 sf0 and sf1 to the list of targets.
 Then the Install() should work as expected.

I disagree.  He's explicitly passing the files in sf to Install();
Install() should always (try to) install all the files given as its
sources.  Whether they're created as side effects or anything else
_shouldn't_ matter.

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

Re: [Scons-dev] Likely bug - installing side effect files

[Gary Oberbrunner]

On Thu, Oct 30, 2014 at 9:34 AM, Ben Golding ben.gold...@synopsys.com wrote:
 tgt = Command('tgt', 'src', 'touch $TARGET sf0 sf1')
   sf = SideEffect([ 'sf0', 'sf1' ], tgt)
   Install('dir', tgt + sf)

I can reproduce this bug.  Please file a ticket!  The dependency tree
looks OK, and I can't easily see the cause of the bug.

Adding sf0 and sf1 to the targets list instead of as side effects makes it work.

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

Re: [Scons-dev] Bonjour de Lyon...

[Gary Oberbrunner]

Bonsoir!  Hope you're enjoying Lyon and the conference; wish I could be there!

On Sun, Oct 26, 2014 at 4:45 AM, Dirk Bächle tshor...@gmx.de wrote:
 Hi there,

 I just wanted to send you all a quick Hello from the PyConFR 2014 in Lyon,
 France. I gave my talk yesterday, so my adrenaline level has dropped to
 something close to normal again by now. ;)
 I'll continue enjoying the weather and the belgian beer, have some fun too!

 Best regards,

 Dirk


 ___
 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

Re: [Scons-dev] modernize 0.4 is released for Python 3 porting experiments

[Gary Oberbrunner]

On Thu, Oct 23, 2014 at 12:07 PM, Russel Winder rus...@winder.org.uk wrote:
 I think we need to resync or abandon the current Python 3 branch,
 currently it is so far behind default/tip that it is not worth working
 on as is.

Really?  I merged default into it not too long ago.

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

Re: [Scons-dev] First Pillar of Future SCons Tools

[Gary Oberbrunner]

On Tue, Sep 30, 2014 at 10:39 AM, Kenny, Jason L
jason.l.ke...@intel.com wrote:
 By this I meant to have a --use-env or something value that would set the 
 Scons environment ENV to that of the shell.

There's nothing wrong with this at the user level, but I don't think
it should be hard-wired into the basic tool logic.  After all what is
the SCons environment?  In my day job we have four or five main ones
(in a single build), plus a couple of one-offs.  It's important to be
able to configure each one from a known starting point (whether by
cloning or custom high-level tools or whatever), and global options
that affect all tools and/or all environments are dangerous from that
standpoint, as useful as they may be.

I see this as a process of layering.  We should make sure the basic
tool/toolchain infrastructure _can_ support things like a global
--use-env, as well as other models.  Best to build general mechanisms
at the lowest level so high-level add-ons like Parts are both possible
and easy.

I feel the same way about your data-driven approach to tool setup.  I
think at the most basic level, tools must be configurable via
arbitrary code.  Higher layers like Parts should be able to layer in
data-driven tool definitions in whatever mini-language is appropriate
for that type of tool, but based on a common, flexible core.  The
data-driven tool spec will always be more rigid but safer and simpler
than arbitrary configuration code, so we need to provide for both
layers to exist.

 The tool would test to see if gcc existed still, but it would trust the user. 
 This was to deal with the cases of:

 1) I have a new test compiler in some .tar.gz/zip setup, it has no standard 
 setup ( or Parts/Scons don't know about it yet as there is no tool) so we 
 just set it up in the shell to get it to work quickly.
 2) I want a quick hack to get something to work
 3) I am setting up a new tool and I am trying to figure out what is missing 
 in the env the tool setups from what is on the shell.

 I see 1) the most at work as we get these prototype setups that have 
 something custom on it. One the testing is done on it they tend to disappear 
 as whatever toolchain is on it becomes more standard. Many of these cases 
 have a custom gcc or intel compiler on it and the user just wants to have 
 version of gcc to be used, not the system one. ( and for some reason it was 
 not installed in /opt and or some other custom thing was done to it that make 
 it difficult to use the standard tool without custom modification of tool 
 code that the developer does not want to do)

 2) is the next most common and seems to happen the most with people on a 
 first pass make - scons/parts pass or they are building on a cluster which 
 has it own set of issues. Mostly it is nice to have an easy way to leak in 
 the shell in controlled way as certain build cases are being corrected to be 
 more repeatable. I view this as hot wiring the build, vs starting a build...

Yes, I agree this is a really interesting use case.

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

Re: [Scons-dev] 2.3.3 Release issue ?

[Gary Oberbrunner]

On Sat, Sep 27, 2014 at 10:36 AM, Dirk Bächle tshor...@gmx.de wrote:
...

 Is it too late to stop you with that? I'm currently working on the fix for
 #2971, and would like to get that into 2.3.4 as well if possible.
 Sorry, I didn't know that a v2.3.4 was planned/pending, else I would've
 spoken up earlier. :P

No problem, I can squeeze it in.  Let me know when you're ready.


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

[Scons-dev] SCons 2.3.4 is released

[Gary Oberbrunner]

SCons version 2.3.3 is now available at the SCons download page,
http://www.scons.org/download.php.  This is a maintenance release to
fix a regression in 2.3.3 in EnsureSConsVersion, and fix a problem
with interactive mode.

As usual, many thanks to all the dedicated people who help keep SCons going!

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

Re: [Scons-dev] 2.3.3 Release issue ?

[Gary Oberbrunner]

On Sun, Sep 21, 2014 at 3:10 PM, alexandre.feb...@gmail.com wrote:

 Hello,

 I see no commit and no pull request about that. Am I overlooking
 something, or has this been forgotten?


Thanks for the reminder, Alexandre.  Yes, we need to take care of this.  (I
was out of the country for a week.)  Does anyone have a patch ready?

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

Re: [Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Tue, Sep 9, 2014 at 4:03 AM, Jean-Baptiste Lab 
jeanbaptiste@gmail.com wrote:

 Or wouldn't it be enough to simply mandate that exists() return something
 that can be tested against True/False?
 If that's the case, wouldn't a bit of wrapping around and implementing the
 __eq__/__neq__ descriptors (possibly __cmp__) be good enough so that we can
 get to the error description when needed (if False) without breaking
 existing usages?


I did think about that.  It's hard for me to imagine something that can
test as false while still having a string value.  Not impossible, but
pretty weird and a bit un-pythonic. I prefer simplicity over cleverness.
 Still, if you have an idea, let me know.

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

Re: [Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Mon, Sep 8, 2014 at 10:24 PM, William Blevins wblevins...@gmail.com
wrote:

 This might be obvious, but it the exception pattern not popular in python?


Sure, but we don't want everyone testing for tool existence to have to wrap
that in an exception handler.

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

Re: [Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Tue, Sep 9, 2014 at 11:08 AM, Kenny, Jason L jason.l.ke...@intel.com
wrote:

  What are your thoughts on infra to help provide a common mean to find
 tools for different platforms.



 I believe what I have in Parts for this work pretty well. It allow an
 extensible and generally easy way for one to define how to find a given
 tool version(s) for a some combination of host and target. Being able to
 update a file with information about a new version without having to modify
 existing code I have found to be a big win. Given cases the how SCons deal
 with the Intel Compler vs how Parts does. It has been very easy for me in
 Parts to support the intel compiler versions and different platforms such
 as x86, x86_64, phi (k1om),ia64 , and some other case I cannot talk about
 for different system ( as window, posix, mac, and some others…). Likewise I
 have little issue with msvc for x86,x86_64, arm as well as WDK cases.



 I believe we when we talk about the toolchains and tools we need to
 consider:

 1)  Host we are on

 2)  What target platform we are building for ( so we select the best
 tool)

 3)  What version ( normally use exactly this version, or best version
 of a certain version ie latest 4.x drop, or the latest). The point here is
 that a tool needs to have a version value ( it might be wild in certain
 cases, but the common case for most tools, is that you can have more than
 one version at a time installed)

 When we configure an environment we need to consider all a setting up the
 value via:

 1)  Some hand defaults

 2)  Processing some script

 3)  Allowing the user to saw just use the shell and trust me

 Make users like 3) the most as that is how make works, and so simple
 builds this is not so bad. But for cross building this is a mess, and for
 teams 1,2 become very useful as this allow for a duplicate-exact setup
 which means the builds are reproducible, cases like 3) require a copy-exact
 setup, and I generally see this get messed up to easily, causing wasted
 time on some strange issue, cause by some difference that was not
 duplicated correctly.


I deliberately want to avoid the complexity of most of what you're
suggesting, at least at the most basic level.  Allow people to build fancy
structures on top if they want.

The current proposal involves a tool registry (not yet adequately
documented in the wiki, sorry) which will help with enumerating available
(and unavailable) tools.  Also, tools can take args, so it'll be possible
to say intelc = ToolIntelC(abi='x86', version='11.1') to get specific ABIs,
path usage, or whatever.  This will be left up to the tool, but I assume
some common conventions will appear.  Your ideas about paths, using
scripts, etc. could be represented as tool args.

As far as making it easier to support different Intel compiler versions, I
don't see any way to make that easier.  Different versions use different
version-numbering conventions, different Windows registry layouts,
different directory layouts... I don't see any way to write common code to
support them all.  But that is not a problem I'm trying to solve for the
Toolchain revamp.  If a particular tool is painful or complex inside,
that's it's problem.  As long as it can present a simple interface to the
outside world, that's good.

Tools in this proposal also have versions themselves, but that's more to
enable a global tool repository, so (someday) people could auto-install
tools, auto-update them, etc.

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

Re: [Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Tue, Sep 9, 2014 at 12:03 PM, Kenny, Jason L jason.l.ke...@intel.com
wrote:

  I think you are missing the point or maybe I am.



 Given the tool revamp.



 How will we support:



 1)  Cross-builds.

 a.   I want to build 32-bit and 64- at the same time

 b.  I want to build for android arm and x86

I have in mind something like this:

  # define and register the tools, by name
  Tool(name='intelc_32_arm', class=Tool.IntelC, abi='ia32', sys='arm')
  Tool.IntelC(name='intelc_64', class=Tool.IntelC, , abi='x86_64',
sys='intel')

 # use them
 env1=Environment(tools=['intelc_32_arm', ...])
 env2 Environment(tools=['intelc_64', ...])


  2)  Selecting different versions of gcc?

Same method.
  Tool(name='ancient_gcc', class=Tool.GCC, version='3.4')

  Environment(tools=['ancient_gcc'])


  3)  How do I iterate over the different versions of a tool that are
 installed

I haven't defined a tool enumeration API yet, but since there's a registry
that stores everything, it shouldn't be hard.

  4)  How do I know this this gcc tool will build x86 code or x86_64
 code, will it be android, mac or linux, phi, etc?

If you use the default version (don't pass special args to the tool), it
ought to auto-detect the current platform.

  5)  I want use gcc not clang with icc or I want to use a given
 version of gcc (or cl) with icc.

Use a toolchain:
  my_tools  = Toolchain(['my_icc', 'ancient_gcc'])


 For me the issue is that SCons makes this HARDER than it needs to be. What
 I am suggesting is that tools have certain traits. Not a lot, just some
 basic stuff, I am suggesting that we need to define in SCons these objects
 to make easy building blocks:



 1)  Platform Object – defines a system os, arch ( maybe more as it
 can be clearly defined). Used to define a HOST and TARGET value in the
 environment ( like in Parts)

I want to avoid having to define and implement this right now -- I think
it's a fine idea, it's just orthogonal to revamping the _basic
infrastructure_ of tools and chains.  If we define a Platform object and
Tool authors take a Platform as one arg for their tool:
  my_platform = Platform(...)
  Tool(name='my_icc', class=Tool.IntelC, platform=my_platform)
then that is great.  But LaTex, m4, SQL, and a million other tools wouldn't
find that Platform object useful or important.  We can layer it in later.

  2)  Tools Object - defines a tool builder, basic variable, tells us
 information ( such as it exists), populates the env[ENV] with needed values
 to run.

Yes. I hope I am achieving this.

  3)  Toolchain allows us to define changes, much like you define

I don't see it as defining changes.  I see it as enabling grouping of tools
into larger clusters or configurations or whatever you call it. Both AND
(all must exist) and OR (select an alternative) are important.

  4)  Configuration – to allow one to easily define common setting to
 apply to a configured tool

Not sure what you're getting at here. Do tool args help?

  5)  Toolsetting/info/finders – a set of basic objects to help find
 information. You seem against this, but I suggest this as building blocks
 to make it easy for a tool to setup and cache, etc a given tool. The fact
 is that most tools have the same pattern and can be configured by replacing
 some basic values.

Are you talking about adding some utility methods to the base Tool class,
like looking up things in paths and registry?  I'm fine with that.

  6)  A version object. I know you might find this complex, but more
 complex version handling this is really useful. And honestly is a common
 need when one is making larger system. You can live without it, but having
 it is really nice, and reduces common errors.

I think this would be nice.  Again, not necessarily as part of the
toolchain revamp, but yes if we had a version object that allowed flexible
comparisons that would be very useful.

I think the idea of a tool registry is a great idea, as long as it can
 support different tools impls of the same tool in some way.


See above.  My current implementation memoizes based on the tool's class
and all the args passed to it.  This assumes that the construction of a
tool isn't dependent on external state, only the class and args.  I
actually think that restriction is useful to clarify and enforce the
underlying concept.  (Right now I have it so if you try to re-register the
tool with the same args, it just returns the original.)  If your tool
should behave differently (when constructed, not just when applied to an
env) then it should take an arg to indicate that.  abi is an obvious one
for C-like tools.

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

Re: [Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Tue, Sep 9, 2014 at 2:07 PM, Kenny, Jason L jason.l.ke...@intel.com
wrote:

  Thanks Gary for your thoughts!

 I have a few thought about the response. But I think I would start off
 with just one item.



 When you look at what you have suggested, we have a cross build you
 suggest something to what I would think..



 env1=Environment(tools=['intelc_32_arm', ...])



 What is wrong with this is that is that the user can say this:



 env1=Environment(tools=['intelc_32_arm', ‘mslink_64_arm’]);



 This allow for a bad and confusing environment. Tools as I would see them
 care about the platform or they don’t ( as you point out many tools may not
 care as they don’t output data that is independent. Ie work on ‘any’
 platform, but even in all your cases they are often 32 and 64 bit version
 of them. which one is being used?)


This is what a toolchain is for, IMHO.  Someone (SCons, tool author or
user) would set up proper toolchains including compiler, linker etc.
 Users would use those as if they were tools:
  env1 = Environment(tools=['intel_32_arm_toolchain']).  Again, at this
most basic tool level, we need to define mechanism and not restrict policy.



 Having the ability to mix 32-bit and 64-bit tools seems dangerous.


Sure, so is mixing wrong versions of NVIDIA CUDA and gcc.  Or MSVC compiler
and Gnu linker.  Or MySQL with Postgres, R with SAS.  And so on and so on.


 That is why I suggest having the environment have a built in notion of
 HOST_PLATFORM and TARGET_PLATFORM.


I dislike global things like this in general.  But I understand the idea
behind it, so let me think about it for a while.  It may be we can come up
with a compromise, like adding a set of kwargs to a Toolchain that gets
merged into all the Tools of that chain.  The current syntax doesn't allow
for that but maybe we can extend it.


 I think that having a restriction that and environment is configured for
 some host-target combination and that the tools configure themselves based
 on that value. Many tools output, or view of Target is a general
 ‘any’/’noarch’ I don’t care.


Well, much more interestingly, many tools' idea of the Platform has nothing
to do with what CPU it's running on.  Might be GPU (NVIDIA/AMD), or
network, or Amazon instance type, or SQL configuration... who knows.  What
you're proposing is too C-centric for a general build tool.  Not saying
it's not hugely useful in that C-centric context, just that it's a layer
up from the base I'm trying to define now.


 However many of these may still value this information to help configure
 which tool to select. It does seem to me that we already have a BKM to try
 to do this.


Not sure what a BKM is.  So far I don't think we need (e.g.) a callback in
an OR toolchain to decide which one to try first, given current machine
state, but it's a possibility.  Or maybe, even going beyond that, we could
have a GeneratorToolchain that doesn't have a static list of tools, but
runs a method to return its tool list.  Hmm, that seems like it might cover
a lot of use cases.


 I agree that we could not do this, but I feel that this would add a larger
 burden on the user to do what is right. Given the samples so far, there is
 a suggestion of lots of tools, with possible random names. This could get
 confusing quickly. I fear that the error handing will become hard, as
 giving a clear message to the user that something is wrong and way will be
 very difficult and will temp many people to start defining tools in a way
 in which they try to know about other tools in unhealthy ways. The user at
 the end of the day just wants to say build this stuff with this tool chain
 for some platform. Ie ‘any’ in some cases, or for android, window, posix,
 mac, etc…



 I think one of the values of SCons is to be easy to use. We tell it what
 we need, and it does it. It has domain knowledge of the “creation” chain,
 so the user can work on their problem.


Yes.  Proper definition of toolchains (including shipping plenty of useful
ones) should help.  Users who want to define their own chains will of
course have to nail down what they want and be responsible for the results.

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

Re: [Scons-dev] Re PR #171

[Gary Oberbrunner]

On Mon, Sep 8, 2014 at 6:35 AM, anatoly techtonik techto...@gmail.com
wrote:

 2to3 makes code incompatible with Python 2.

 With modernize it is possible to go one fixer at a time and bisect errors
 later.


I believe individual fixers were applied and python2 compatibility has been
added back in a piece at a time.  It's not complete but a lot of tests pass
both on python2 and python3.  You can try it.  Patches gratefully accepted!

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

Re: [Scons-dev] 2.3.3 Release issue ?

[Gary Oberbrunner]

Grr.  Oh well.

On Mon, Sep 8, 2014 at 1:47 PM, anatoly techtonik techto...@gmail.com
wrote:

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


I'm here, but am pretty busy at the moment.  This weekend I will be away.
 Please start by making a pull request with the fix.


 On Mon, Sep 8, 2014 at 8:27 PM, anatoly techtonik techto...@gmail.com
 wrote:
  I wonder why buildbots are silent about this?


Good question, if we need a new test as part of the test suite please add
it to the patch.

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

Re: [Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Mon, Sep 8, 2014 at 12:19 PM, Kenny, Jason L jason.l.ke...@intel.com
wrote:

  SO I am all for improving the Tools logic. This was a big part of the
 work I did in Parts. Given what I have, I know there are some more tweaks I
 would like to make.



 Is there a process in how to add proposal to this wiki page. I know I
 would like to propose a possible infra set of objects to make it easier to
 find and set up a working tools environment. ( ie what is need to run
 command correctly)



 Also a general statement. Do we want to say SCons errors or warns when a
 tool in a toolchain is not found. I have taken a view that it should error
 out with information. ( for example the user might have stated they want
 icc v12.1, parts might error out given that it is not installed tell the
 user that 13.1 was found not 12.1). I have found that warnings turn to
 noise more often than not and are ignored ( or missed as the text just
 scrolls to fast). When the “error” does happen later ( and it will) the
 user is annoyed that had time wasted.



 For me it seems to me that is a toolchain is not resolvable we need to
 error.


The current proposal is that a Tool's exists() should _return_ an error
message but not throw or print anything.  The toolchain logic above it can
then test silently and decide what to do.



 I would also state that we want to allow define one toolchain per env.
 Some toolchains cannot be mixed. And having a different env just makes it
 work better. D and C++ seems to a common case here. However this is more
 complex, as different chains could be mixed as they are independent. Being
 able to define what toolchain to use up front, vs having a default chain (
 which takes time and is a result of certain annoying warning on windows at
 time) seem to be a good solution, as we can provide chains, and allow then
 chain to complain is there are known incompatible issues.


 The current proposal is that a Toolchain is either AND (all must exist) or
OR (first one wins).  Toolchains can have other toolchains as members as
well as Tools.  Any element in a Toolchain can be marked as Optional (which
means if it's in an AND toolchain it doesn't fail that toolchain if it
doesn't exist).  I have some simple test code for this working.

I hope this architecture is flexible enough that we can have one master
toolchain per system; that one would have sub-toolchains for C/C++ (which
would consist of an OR toolchain for Intel, MSVC, gcc/mingw, gcc/cygwin and
whatever else we want), SWIG, D, LaTeX, and whatever else we want.  I'm
also hoping (don't have any of this working or even really designed yet) to
make it easy enough to replace or add to the default toolchain that we can
make the default pretty minimal; users would add what they need.

I also think it's flexible enough to give decent and appropriate error
messages when the toolchain requirements aren't met.

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

Re: [Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Mon, Sep 8, 2014 at 4:13 PM, Kenny, Jason L jason.l.ke...@intel.com
wrote:

 Ideally I always viewed this as a True False statement. I see you have it
 returning a tuple.



 I only worry that I have seen a lot push with certain python developers to
 say stuff like



 if not tool.exists():

 # do something…



 This will not work as we will have a (True,””) or (False,””) return API.
 This seems to me to more complex to use and understand. At the very least
 east to trip up on. If we want an object returned. I think it will be
 better to define a error object that can be tested as True or False vs
 forcing tuple separation on returns values.


Excellent point.  The 'if not tool.exists()' pattern needs to work.  I'll
rethink that.  Maybe something as simple as tool.exist_error() which can be
called just after exists() returns False...

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

Re: [Scons-dev] Windows Path

[Gary Oberbrunner]

On Sun, Sep 7, 2014 at 9:45 AM, alexandre.feb...@gmail.com wrote:


 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() !


I agree, Alexandre -- although it's clever, I think it'd be a bit _too_
clever for production use everywhere.  Too many things to go wrong.
 Simpler is better, even if it means full paths.

One thing I'm considering for the toolchain revamp is this: should a tool
be able to have a hook which modifies the environment temporarily just
before the executable runs?  That way it could temporarily add to the path.
 But I think even this is too clever; people want to be able to print out
the env and see what it's going to do, for debugging or whatever.  Plus
there's the consideration of should that same hook be run in a generator or
scanner or other places.

At the end of the day, I think we'll have to decide on a tool-by-tool basis
between (a) adding the tool's bin dir to $PATH and (b) using the tool's
full path.  I don't think there is one answer that's right for everyone.
 Here's a question for folks familiar with other similar build tools: what
do they do?  Cmake, waf, gradle, etc.?

One thing I think is definitely important for the new toolchain system is
that tools will be able to take arguments.  So at least in some cases we
could leave this decision to users; a gcc on Windows tool could have an
add_to_os_path=False arg for instance.  I'm still working on how to expose
those tool args in a reasonable way.

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

Re: [Scons-dev] Multi-platform development

[Gary Oberbrunner]

On Sun, Sep 7, 2014 at 9:50 AM, Russel Winder rus...@winder.org.uk wrote:

 Because I have Python 3 installed as default I have a symbolic link
 python2 to 2.7:

 python2 runtest.py test/D

 leads to an error in shutil.copytree at QMTest/TestCmd.py line 1275.

 shutil.py line 208 is raising an exception operation not permitted
 on /private/tmp/testcmd.98136.Tj_v70/./p/submodule2.d


This could simply be how you've configured samba on the linux side.  There
are various security options; check e.g.
https://www.samba.org/samba/docs/using_samba/ch09.html.

Also try using PRESERVE=1 and look at the permissions in
/private/tmp/testcmd.tmpname

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

Re: [Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Sat, Sep 6, 2014 at 5:42 AM, Russel Winder rus...@winder.org.uk wrote:

 OK so I am abandoning all my scruples and trying to get SCons running on
 my wife's Windows 7 machine so as to run some tests on Linux, OSX *and*
 Windows.

 I have now discovered that on a 64-bit laptop running Windows 7:

 Environment()['PLATFORM']

 return win32. One assumes there is some existentialist humour present in
 this result?


It's the Windows Way -- sys.platform() also returns win32 on 64-bit
machines; system files are in /Windows/System32, and so on and so on.


 Also at every turn I am told:

 scons: warning: No version of Visual Studio compiler found – C/C++
 compilers most likely not set correctly
 File … engine\SCons\Script\Main.py, line 602, in
 _scons_internal_warning


Yes, known problem.  The right solution is the toolchain revamp.  A less
invasive solution is surprisingly hard to find, though Anatoly has a
possible idea.
If you initialize your Environment with only the tools of interest, you
won't see that warning.

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

Re: [Scons-dev] Multi-platform development

[Gary Oberbrunner]

On Sat, Sep 6, 2014 at 4:12 AM, Russel Winder rus...@winder.org.uk wrote:

 It appears to be impossible to run SCons tests from an OSX machine using
 SMB mounted filestore from a Linux machine.


Since I know OSX requires the root filesystem to be HFS+, I guess you're
trying to mount your SCons source tree remotely via SMB/CIFS and run the
test suite from there?  I'd expect that to work.  What fails?  Could it be
caused by your SAMBA config on Linux?


 Has anyone found a way of working with a single filestore and two
 platforms so as to develop for multiple platforms at the same time?


If you just copy the SCons source tree onto the HFS+ drive does it work
then?

-- Gary


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

Re: [Scons-dev] Time for a show down…

[Gary Oberbrunner]

On Sat, Sep 6, 2014 at 6:16 AM, Russel Winder rus...@winder.org.uk wrote:

 TestSCons.TestSCons.where_is searches the user's path for an executable.
 When running tests SCons does not use the users path, just the default
 system path, to search for executables. where_is is therefore either
 broken or useless.


I hear you.  Let's say it is broken.  What's the fix?  Don't use $PATH by
default?

Some tests want to deliberately look in $PATH and set up the test
accordingly;
maybe the simple fix is just to not use os.environ['PATH'] when the
passed-in
optional path arg is None.  Any test that really wants that would have to
explicitly pass os.environ['PATH'].  I wonder how many tests that would
break.

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

Re: [Scons-dev] Mercurial Workflow v2 (WIP)

[Gary Oberbrunner]

On Sat, Sep 6, 2014 at 1:54 AM, anatoly techtonik techto...@gmail.com
wrote:

 Updated with rebase instructions. Need to revise
 the part about working with multiple features at
 once. It looks like it is better to split to separate
 pages, because there can be alternatives.


This looks good, Anatoly!  Thanks.

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

Re: [Scons-dev] Time for a show down…

[Gary Oberbrunner]

On Sat, Sep 6, 2014 at 6:27 AM, Gary Oberbrunner ga...@oberbrunner.com
wrote:

 Some tests want to deliberately look in $PATH and set up the test
 accordingly;
 maybe the simple fix is just to not use os.environ['PATH'] when the
 passed-in
 optional path arg is None.  Any test that really wants that would have to
 explicitly pass os.environ['PATH'].  I wonder how many tests that would
 break.


On my Linux box (Ubuntu 12.04), no new tests fail if I comment out the
lines in TestSCons.TestSCons.where_is that set path = os.environ['PATH'].

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

Re: [Scons-dev] Quick Sanity Check

[Gary Oberbrunner]

On Mon, Sep 1, 2014 at 3:29 PM, Russel Winder rus...@winder.org.uk wrote:

 On Sun, 2014-08-31 at 18:03 -0400, Gary Oberbrunner wrote:
  That branch is the one.  If you check the commits on that branch you'll
 see
  who's been committing to it.  I just yesterday got a python3 installed,
 so
  I haven't touched it under python3, though I have kept pushing it back
 into
  functioning on python2 (but not all the way there yet either).  So yeah,
  there is plenty of juicy low-hanging fruit. :-)

 So we still need to answer to question: does the python3 branch need to
 run with Python 2. If no fine, I can really cope with that. If yes then
 which version of Python 2.7, there are so many, and the larger the z in
 2.7.z the more Python 3 features are available.

 Yes, we want python2.7 and 3.  2.7 is the stated floor.  If we can keep
most things working in 2.6 that is a plus (i.e. we should try not to make
it fail immediately on startup with 2.6; many people just do simple things
with SCons.)

If there are particular features in the 2.7.x stream we should, or need to,
care about, lay them out here and let's discuss.

I think we've said that 3.x means 3.3 or later but I could be wrong about
that detail.

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